Skip to contentSkip to conversation

hpt374 sata (Highpoint Rocket 1540)

DISCUSSION Bob Ham 5 participants 25 messages Jul 31, 2007 – Aug 5, 2007 libata

lore
Share & tools
lore

Bob Ham

author
#0 lore raw

Hi there,

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. There are rumours[0][1] of a SATA driver for the hpt372N/302N chips using libata. In 2.6.22, there are PATA drivers for hpt3xx, but no SATA.

[0] http://linuxmafia.com/faq/Hardware/sata.html#highpoint
[1] http://lkml.org/lkml/2006/1/3/211

I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards?

Cheers,

Bob Ham

#1 lore raw
Quoted 2 lines

I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards?

The HPT374 is a PATA controller. Some people ship products with the HPT37x controllers and PATA/SATA bridges and those should work with the libata drivers.

author
#2 lore raw
Quoted 6 lines · Alan Cox
Quoted 2 lines

I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards?

The HPT374 is a PATA controller. Some people ship products with the HPT37x controllers and PATA/SATA bridges and those should work with the libata drivers.

Might I suggest something along the lines of the attached patch in order to avoid future confusion? The information on which cards have which chips comes from the linuxmafia web page.

Bob

Signature · 1 line
Bob Ham <[email protected]>
Kconfig renamed from Kconfig.old +11 -1
@@ -297,6 +297,11 @@
 	  This option enables support for the majority of the later HPT
 	  PATA controllers via the new ATA layer.
 
+	  Some SATA cards, like the Highpoint Rocket/RocketRAID
+	  1540/1542/1544/1640 and some versions of the RocketRAID 1520,
+	  use these PATA controllers in conjunction with a SATA/PATA
+	  bridge. This driver should support those cards, too.
+
 	  If unsure, say N.
 
 config PATA_HPT3X2N

@@ -304,7 +309,12 @@
 	depends on PCI && EXPERIMENTAL
 	help
 	  This option enables support for the N variant HPT PATA
-	  controllers via the new ATA layer
+	  controllers via the new ATA layer.
+
+	  Some SATA cards, like the Highpoint Rocket 1520 and some
+	  versions of the RocketRAID 1520, use these PATA controllers
+	  in conjunction with a SATA/PATA bridge. This driver should
+	  support those cards, too.
 
 	  If unsure, say N.
#3 lore raw
In reply to Bob Ham
Quoted 4 lines · Bob Ham

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?

Quoted 2 lines

I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards?

As HPT374 is not a SATA chip, it needs SATA bridges to work with SATA
drives, hence no the only HPT374 libata driver that's going to ever be is pata_hpt37x.

Quoted 2 lines

Cheers,
Bob Ham

MBR, Sergei

#4 lore raw
Quoted 5 lines · Sergei Shtylyov
Quoted 2 lines

I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards?

As HPT374 is not a SATA chip, it needs SATA bridges to work with SATA
drives, hence no the only HPT374 libata driver that's going to ever be is pata_hpt37x.

I've 2 of these cards lying around and when I last tested one of them ~2.6.20 thereabouts it worked as well as a pair of sil3112 cards provided you don't want hotplug. I have a test box here I'll fire up next week when I get some more sata drives to play with.

Brad

Signature · 3 lines
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
#5 lore raw
In reply to Sergei Shtylyov
Quoted 6 lines · Hello, I wrote:
Quoted 4 lines

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. I wonders if R1540 could be
identified via the subsystem ID -- SATA bridges HPT uses seem to have limitations WRT DMA modes, i.e. no MWDMA and UDMA modes 0, 4 and higher only are supported...

Quoted 2 lines
Quoted 2 lines

Cheers,
Bob Ham

MBR, Sergei

author
#6 lore raw
Quoted 10 lines · Sergei Shtylyov
Quoted 6 lines · Hello, I wrote:
Quoted 4 lines

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.

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

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.

lspci gives:

00:0d.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
Subsystem: Triones Technologies, Inc. Unknown device 0001
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at efa0 [size=8]
I/O ports at ef9c [size=4]
I/O ports at ef90 [size=8]
I/O ports at ef98 [size=4]
I/O ports at ec00 [size=256]
Expansion ROM at fe700000 [disabled] [size=128K]
Capabilities: [60] Power Management version 2

00:0d.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
Subsystem: Triones Technologies, Inc. Unknown device 0001
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at eff0 [size=8]
I/O ports at efe4 [size=4]
I/O ports at efa8 [size=8]
I/O ports at efe0 [size=4]
I/O ports at ed00 [size=256]
Capabilities: [60] Power Management version 2

Bob

Signature · 1 line
Bob Ham <[email protected]>
#7 lore raw

Hi,

Quoted 31 lines · Bob Ham
Quoted 10 lines · Sergei Shtylyov
Quoted 6 lines · Hello, I wrote:
Quoted 4 lines

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.

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
Quoted 6 lines

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?

[PATCH] hpt366: always tune PIO

Cc Sergei Shtylyov <[email protected]>
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
 drivers/ide/pci/hpt366.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/ide/pci/hpt366.c +4 -4
Index: 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;
author
#8 lore raw
Quoted 6 lines · Bartlomiej Zolnierkiewicz

Hi,

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

The hpt366 driver freezes on
boot, as reported by others.

Does this patch change anything?

Unfortunately not.

Signature · 1 line
Bob Ham <[email protected]>
#9 lore raw
In reply to Bartlomiej Zolnierkiewicz

Hello.

Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines

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

Quoted 17 lines
Quoted 17 lines

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

Quoted 8 lines
Quoted 6 lines

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

Quoted 17 lines

[PATCH] hpt366: always tune PIO

Index: b/drivers/ide/pci/hpt366.c
===================================================================

drivers/ide/pci/hpt366.c +1 -1
@@ -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);

drivers/ide/pci/hpt366.c static void __devinit init_hwif_hpt366(i · line 1274

Quoted 10 lines
drivers/ide/pci/hpt366.c +3 -3
-	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

author
#10 lore raw
Quoted 9 lines · Sergei Shtylyov

Hello.

Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

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 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

Can we see a bootlog please?

... and the output of 'lspci -v' too.

If possible, turn off that driver,
then post that output...

This is the output of the boot using the pata_hpt37x driver:

Linux version 2.6.22.1 (rah@teasel) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #6 Tue Jul 31 20:23:11 BST 2007 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ff40000 (usable)
BIOS-e820: 000000001ff40000 - 000000001ff50000 (ACPI data)
BIOS-e820: 000000001ff50000 - 0000000020000000 (ACPI NVS)
BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000ff780
Entering add_active_range(0, 0, 130880) 0 entries of 256 used Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 130880
early_node_map[1] active PFN ranges

    0:        0 ->   130880

On node 0 totalpages: 130880
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 990 pages used for memmap
Normal zone: 125794 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP 000F91A0, 0014 (r0 ACPIAM)
ACPI: RSDT 1FF40000, 0030 (r1 A M I OEMRSDT 9000424 MSFT 97)
ACPI: FACP 1FF40200, 0081 (r2 A M I OEMFACP 9000424 MSFT 97)
ACPI: DSDT 1FF40350, 373D (r1 A0008 A0008705 705 INTL 2002026)
ACPI: FACS 1FF50000, 0040
ACPI: APIC 1FF40300, 004A (r1 A M I OEMAPIC 9000424 MSFT 97)
ACPI: OEMB 1FF50040, 003F (r1 A M I OEMBIOS 9000424 MSFT 97)
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 30000000 (gap: 20000000:df7c0000) Built 1 zonelists. Total pages: 129858
Kernel command line: root=/dev/sda1 ro devfs=mount vga=0x313 mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1666.560 MHz processor.
Console: colour VGA+ 132x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 511900k/523520k available (2566k kernel code, 11044k reserved, 1040k data, 188k init, 0k highmem)
virtual kernel memory layout:

    fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
    vmalloc : 0xe0800000 - 0xfffb5000   ( 503 MB)
    lowmem  : 0xc0000000 - 0xdff40000   ( 511 MB)
      .init : 0xc0488000 - 0xc04b7000   ( 188 kB)
      .data : 0xc0381845 - 0xc0485c04   (1040 kB)
      .text : 0xc0100000 - 0xc0381845   (2566 kB)

Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3336.73 BogoMIPS (lpj=6673476)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000420 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
CPU: AMD Sempron(tm) 2400+ stepping 01
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: enabled onboard AC97/MC97 devices
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 14 15) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
PnPBIOS: Disabled by ACPI PNP
SCSI subsystem initialized
libata version 2.21 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
ACPI: RTC can wake from S4
pnp: 00:08: iomem range 0xfec80000-0xfec800ff has been reserved
pnp: 00:08: iomem range 0xfec00000-0xfec00fff has been reserved
pnp: 00:08: iomem range 0xfee00000-0xfee00fff has been reserved
pnp: 00:08: iomem range 0xfff80000-0xffffffff could not be reserved
pnp: 00:09: ioport range 0x480-0x487 has been reserved
pnp: 00:09: ioport range 0xc00-0xc7f has been reserved
pnp: 00:0b: iomem range 0x0-0x9ffff could not be reserved
Time: tsc clocksource has been installed.
pnp: 00:0b: iomem range 0xc0000-0xdffff could not be reserved
pnp: 00:0b: iomem range 0xe0000-0xfffff could not be reserved
pnp: 00:0b: iomem range 0x100000-0x1fffffff could not be reserved
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Setting latency timer of device 0000:00:01.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 5, 131072 bytes) TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384) TCP reno registered
Unpacking initramfs... done
Freeing initrd memory: 2474k freed
Machine check exception polling timer started.
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Installing knfsd (copyright (C) 1996 [email protected]).
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: VIA PCI bridge detected. Disabling DAC.
PCI: Bypassing VIA 8237 APIC De-Assert Message
Boot video device is 0000:00:13.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using get_cycles().
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
loop: module loaded
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <[email protected]> sata_via 0000:00:0f.0: version 2.2
ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 16 sata_via 0000:00:0f.0: routed to hard irq line 11
scsi0 : sata_via
scsi1 : sata_via
ata1: SATA max UDMA/133 cmd 0x0001ef88 ctl 0x0001ef86 bmdma 0x0001eeb0 irq 16
ata2: SATA max UDMA/133 cmd 0x0001ef68 ctl 0x0001ef82 bmdma 0x0001eeb8 irq 16
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: WDC WD400JD-22MSA1, 10.01E01, max UDMA/133 ata1.00: 78165360 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/133
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-6: WDC WD2000JD-00HBB0, 08.02D08, max UDMA/133 ata2.00: 390721968 sectors, multi 16: LBA48
ata2.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA WDC WD400JD-22MS 10.0 PQ: 0
ANSI: 5
sd 0:0:0:0: [sda] 78165360 512-byte hardware sectors (40021 MB) sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 78165360 512-byte hardware sectors (40021 MB) sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 1:0:0:0: Direct-Access ATA WDC WD2000JD-00H 08.0 PQ: 0
ANSI: 5
sd 1:0:0:0: [sdb] 390721968 512-byte hardware sectors (200050 MB) sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sdb] 390721968 512-byte hardware sectors (200050 MB) sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1
sd 1:0:0:0: [sdb] Attached SCSI disk
ACPI: PCI Interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 17 ehci_hcd 0000:00:10.4: EHCI Host Controller
ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:10.4: irq 17, io mem 0xfea00000
ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 17 uhci_hcd 0000:00:10.0: UHCI Host Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:10.0: irq 17, io base 0x0000eec0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 17 uhci_hcd 0000:00:10.1: UHCI Host Controller
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3 uhci_hcd 0000:00:10.1: irq 17, io base 0x0000ef00
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 17 uhci_hcd 0000:00:10.2: UHCI Host Controller
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4 uhci_hcd 0000:00:10.2: irq 17, io base 0x0000ef20
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 17 uhci_hcd 0000:00:10.3: UHCI Host Controller
uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 5 uhci_hcd 0000:00:10.3: irq 17, io base 0x0000ef40
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input0
input: AT Translated Set 2 keyboard as /class/input/input1 rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one year, y3k
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
raid6: int32x1 601 MB/s
raid6: int32x2 802 MB/s
raid6: int32x4 623 MB/s
raid6: int32x8 421 MB/s
raid6: mmxx1 1391 MB/s
raid6: mmxx2 2161 MB/s
raid6: sse1x1 1277 MB/s
raid6: sse1x2 2021 MB/s
raid6: using algorithm sse1x2 (2021 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: automatically using best checksumming function: pIII_sse
pIII_sse : 3847.000 MB/sec
raid5: using function: pIII_sse (3847.000 MB/sec)
md: multipath personality registered for level -4
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised:
[email protected]
TCP cubic registered
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
sit0: Disabled Privacy Extensions
NET: Registered protocol family 17
CCID: Registered CCID 3 (ccid3)
CCID: Registered CCID 2 (ccid2)
SCTP: Hash tables configured (established 16384 bind 32768) Using IPI Shortcut mode
rtc_cmos 00:02: setting the system clock to 2007-07-31 19:57:54 (1185911874)
Freeing unused kernel memory: 188k freed
ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 18 (level, low) -> IRQ 18 skge 1.11 addr 0xfe500000 irq 18 chip Yukon-Lite rev 9
skge eth0: addr 00:11:d8:5f:fe:30
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
ACPI: PCI Interrupt 0000:00:0e.0[A] -> GSI 17 (level, low) -> IRQ 19
eth1: VIA Rhine II at 0xfe900000, 00:05:5d:01:96:2b, IRQ 19.
eth1: MII PHY found at address 8, status 0x782d advertising 01e1 Link 45e1.
NET: Registered protocol family 1
hpt37x: DPLL did not stabilize.
pata_hpt37x: BIOS has not set timing clocks.
hpt37x: DPLL did not stabilize.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode. parport_pc 00:06: reported by Plug and Play ACPI
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Adding 1959920k swap on /dev/scsi/host0/bus0/target0/lun0/part2. Priority:-1 extents:1 across:1959920k
EXT3 FS on sda1, internal journal
md: md0 stopped.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-3, internal journal
EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-0, internal journal
EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
skge eth1: enabling interface
ADDRCONF(NETDEV_UP): eth1: link is not ready
ip_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (4090 buckets, 32720 max)
ip6_tables: (C) 2000-2006 Netfilter Core Team
skge eth1: Link is up at 100 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
eth0: no IPv6 routers present
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period

Signature · 1 line
Bob Ham <[email protected]>
#11 lore raw
Quoted 5 lines · Bob Ham
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

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 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

Can we see a bootlog please?

... and the output of 'lspci -v' too.

If possible, turn off that driver,
then post that output...

This is the output of the boot using the pata_hpt37x driver:

Hrm... what I asked for was 'lspci -v' output. :-)

Quoted 3 lines

hpt37x: DPLL did not stabilize.
pata_hpt37x: BIOS has not set timing clocks.
hpt37x: DPLL did not stabilize.

Yes, this ia a known issue, and the fix for it is in the -mm tree:

http://kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fpeople%2Fakpm%2Fpatches%2F2.6%2F2.6.23-rc1%2F2.6.23-rc1-mm2%2F2.6.23-rc1-mm2.bz2;z=950

WBR, Sergei

author
#12 lore raw
Quoted 17 lines · Sergei Shtylyov
Quoted 5 lines · Bob Ham
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

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 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

Can we see a bootlog please?

... and the output of 'lspci -v' too.

If possible, turn off that driver,
then post that output...

This is the output of the boot using the pata_hpt37x driver:

Hrm... what I asked for was 'lspci -v' output. :-)

Quoted 13 lines · Bob Ham

lspci gives:

00:0d.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
Subsystem: Triones Technologies, Inc. Unknown device 0001
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at efa0 [size=8]
I/O ports at ef9c [size=4]
I/O ports at ef90 [size=8]
I/O ports at ef98 [size=4]
I/O ports at ec00 [size=256]
Expansion ROM at fe700000 [disabled] [size=128K]
Capabilities: [60] Power Management version 2

Quoted 9 lines

00:0d.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
Subsystem: Triones Technologies, Inc. Unknown device 0001
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at eff0 [size=8]
I/O ports at efe4 [size=4]
I/O ports at efa8 [size=8]
I/O ports at efe0 [size=4]
I/O ports at ed00 [size=256]
Capabilities: [60] Power Management version 2

I'll check out the patch you pointed to.

Signature · 1 line
Bob Ham <[email protected]>
#13 lore raw
Quoted 29 lines · Bob Ham
Quoted 29 lines
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

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 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

Can we see a bootlog please?

... and the output of 'lspci -v' too.

If possible, turn off that driver,
then post that output...

This is the output of the boot using the pata_hpt37x driver:

Hrm... what I asked for was 'lspci -v' output. :-)

lspci gives:

00:0d.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
Subsystem: Triones Technologies, Inc. Unknown device 0001
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at efa0 [size=8]
I/O ports at ef9c [size=4]
I/O ports at ef90 [size=8]
I/O ports at ef98 [size=4]
I/O ports at ec00 [size=256]
Expansion ROM at fe700000 [disabled] [size=128K]
Capabilities: [60] Power Management version 2

Quoted 9 lines
Quoted 9 lines

00:0d.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
Subsystem: Triones Technologies, Inc. Unknown device 0001
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at eff0 [size=8]
I/O ports at efe4 [size=4]
I/O ports at efa8 [size=8]
I/O ports at efe0 [size=4]
I/O ports at ed00 [size=256]
Capabilities: [60] Power Management version 2

Too bad, this is the standard HPT subsystem ID of 0x0001... So, nothing
comes to my mind other than add a module parameter to hpt366.c to specify that we're using the crippled SATA bridge... well, maybe it would also make sense to scan the BIOS for the signatures...

WBR, Sergei

#14 lore raw
Quoted 4 lines
    Too bad, this is the standard HPT subsystem ID of 0x0001... So, nothing

comes to my mind other than add a module parameter to hpt366.c to specify that we're using the crippled SATA bridge... well, maybe it would also make sense to scan the BIOS for the signatures...

Since you don't do a reset is it not sufficient to check word93 on the initial identify scan in PIO. Or if you do a reset the signature.

#15 lore raw
Quoted 4 lines · Alan Cox
Quoted 2 lines

Too bad, this is the standard HPT subsystem ID of 0x0001... So, nothing
comes to my mind other than add a module parameter to hpt366.c to specify that we're using the crippled SATA bridge... well, maybe it would also make sense to scan the BIOS for the signatures...

Since you don't do a reset is it not sufficient to check word93 on the

Ah, you mean to identify a SATA drive? Need to try this...

Quoted 1 line

initial identify scan in PIO. Or if you do a reset the signature.

Hm, the taskfile signature, you mean?..

MBR, Sergei

#16 lore raw
Quoted 3 lines
Quoted 1 line

Since you don't do a reset is it not sufficient to check word93 on the

Ah, you mean to identify a SATA drive? Need to try this...

That is the basic approach libata uses, and I've been runnin for a while with patches to actually pick this case up and flip the cable type as well. PATA controller/SATA drive rather gives away the presence of a bridge, although which end is one thing I've yet to work out a way to probe

Quoted 3 lines
Quoted 1 line

initial identify scan in PIO. Or if you do a reset the signature.

Hm, the taskfile signature, you mean?..

Yes because that is if I remember rightly also different for a SATA device

author
#17 lore raw
In reply to Sergei Shtylyov
Quoted 5 lines · Sergei Shtylyov
Quoted 3 lines

hpt37x: DPLL did not stabilize.
pata_hpt37x: BIOS has not set timing clocks.
hpt37x: DPLL did not stabilize.

Yes, this ia a known issue, and the fix for it is in the -mm tree:

I applied just that pata_hpt37x.c patch, not the whole -mm tree. It locks the machine hard again. Here is the transcribed output:

hpt37x: Bus clock 66 MHz, using DPLL.
ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17
scsi2: pata_hpt37x
scsi3: pata_hpt37x
ata3: PATA max UDMA/100 cmd 0x0001efa0 ctl 0x0001ef9e bmdma 0x0001ec00 irq 17
ata4: PATA max UDMA/100 cmd 0x0001ef90 ctl 0x0001ef9a bmdma 0x0001ec00 irq 17

Signature · 1 line
Bob Ham <[email protected]>
#18 lore raw
Quoted 10 lines · Bob Ham
Quoted 5 lines
Quoted 3 lines

hpt37x: DPLL did not stabilize.
pata_hpt37x: BIOS has not set timing clocks.
hpt37x: DPLL did not stabilize.

Yes, this ia a known issue, and the fix for it is in the -mm tree:

I applied just that pata_hpt37x.c patch, not the whole -mm tree. It locks the machine hard again. Here is the transcribed output:

hpt37x: Bus clock 66 MHz, using DPLL.

Oh?! hpt366.c detected 33 MHz... :-O

Quoted 5 lines

ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17
scsi2: pata_hpt37x
scsi3: pata_hpt37x
ata3: PATA max UDMA/100 cmd 0x0001efa0 ctl 0x0001ef9e bmdma 0x0001ec00 irq 17
ata4: PATA max UDMA/100 cmd 0x0001ef90 ctl 0x0001ef9a bmdma 0x0001ec00 irq 17

MBR, Sergei

#19 lore raw
Quoted 3 lines
Quoted 1 line

hpt37x: Bus clock 66 MHz, using DPLL.

    Oh?! hpt366.c detected 33 MHz... :-O

Interesting as it should be using the same algorithm as hpt366 now.

Quoted 6 lines
Quoted 5 lines

ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17
scsi2: pata_hpt37x
scsi3: pata_hpt37x
ata3: PATA max UDMA/100 cmd 0x0001efa0 ctl 0x0001ef9e bmdma 0x0001ec00 irq 17
ata4: PATA max UDMA/100 cmd 0x0001ef90 ctl 0x0001ef9a bmdma 0x0001ec00 irq 17

and it also knows about the bridge knobbling stuff. Most curious

#20 lore raw

Hello.

Quoted 5 lines · Alan Cox
Quoted 3 lines
Quoted 1 line

hpt37x: Bus clock 66 MHz, using DPLL.

   Oh?! hpt366.c detected 33 MHz... :-O

Interesting as it should be using the same algorithm as hpt366 now.

Actually not: when pata_hpt37x decides to use DPLL, it reports the chosen
*DPLL* clock instead of the PCI clock. The question is why it chose 66 MHz on HPT374... Looks like it's because of this wrong mask which should be 0xc0:

		dpll = 2;
                if (port->udma_mask & 0xE0)
                        dpll = 3;
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines

ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17
scsi2: pata_hpt37x
scsi3: pata_hpt37x
ata3: PATA max UDMA/100 cmd 0x0001efa0 ctl 0x0001ef9e bmdma 0x0001ec00 irq 17
ata4: PATA max UDMA/100 cmd 0x0001ef90 ctl 0x0001ef9a bmdma 0x0001ec00 irq 17

and it also knows about the bridge knobbling stuff. Most curious

Not curious at all now. ;-) The former HPT374 clocking fix just remained
ineffective.

MBR, Sergei

#21 lore raw
In reply to Sergei Shtylyov

Hi,

Quoted 3 lines · Sergei Shtylyov
Quoted 1 line

Does this patch change anything?

Heh, did you *really* hope it will? :-D

Well, ugh, yes? :)

Quoted 25 lines
Quoted 25 lines

[PATCH] hpt366: always tune PIO

Index: b/drivers/ide/pci/hpt366.c
===================================================================

drivers/ide/pci/hpt366.c +4 -4
@@ -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;
-	}
Quoted 8 lines

drivers/ide/pci/hpt366.c static void __devinit init_hwif_hpt366(i · line 1274

Quoted 2 lines
drivers/ide/pci/hpt366.c +0 -0
 	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)

Without ->autotune timings for PIO data transfers are never set and we need to have a valid settings for some commands (IDENTIFY, SMART data) even if DMA is not going to be used. Thus why I was hoping that this patch might be of some help.

Quoted 5 lines

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

Please do.

Thanks,
Bart

#22 lore raw
Quoted 7 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Sergei Shtylyov
Quoted 1 line

Does this patch change anything?

Heh, did you *really* hope it will? :-D

Well, ugh, yes? :)

Here we have some really nasty screw-up I'm afraid...

Quoted 25 lines
Quoted 25 lines
Quoted 25 lines

[PATCH] hpt366: always tune PIO

Index: b/drivers/ide/pci/hpt366.c
===================================================================

drivers/ide/pci/hpt366.c +4 -4
@@ -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;
-	}
Quoted 7 lines
Quoted 5 lines

drivers/ide/pci/hpt366.c static void __devinit init_hwif_hpt366(i · line 1274

Quoted 2 lines
drivers/ide/pci/hpt366.c +0 -0
 	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)

Without ->autotune timings for PIO data transfers are never set and we need

The will get overwritten by DMA timings anyway. Although... you're right,
with UltraDMA 16-bit PIO timings aren't going to be changed from the defaults.

Quoted 3 lines

to have a valid settings for some commands (IDENTIFY, SMART data) even if DMA is not going to be used. Thus why I was hoping that this patch might be of some help.

There's always default settings. ;-)

Quoted 4 lines
Quoted 2 lines

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

Please do.

In my copious free time. :-)

Quoted 2 lines

Thanks,
Bart

MBR, Sergei

#23 lore raw
Quoted 45 lines · Sergei Shtylyov
Quoted 7 lines · Bartlomiej Zolnierkiewicz
Quoted 3 lines · Sergei Shtylyov
Quoted 1 line

Does this patch change anything?

Heh, did you *really* hope it will? :-D

Well, ugh, yes? :)

Here we have some really nasty screw-up I'm afraid...

Quoted 33 lines
Quoted 33 lines
Quoted 17 lines

[PATCH] hpt366: always tune PIO

Index: b/drivers/ide/pci/hpt366.c
===================================================================

drivers/ide/pci/hpt366.c +1 -1
@@ -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);

drivers/ide/pci/hpt366.c static void __devinit init_hwif_hpt366(i · line 1274

Quoted 10 lines
drivers/ide/pci/hpt366.c +3 -3
-	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)

Quoted 3 lines
Quoted 1 line

Without ->autotune timings for PIO data transfers are never set and we need

The will get overwritten by DMA timings anyway. Although... you're right,

Shouldn't be a real issue - for the usual case (PIO4/MWDMA2) it is not a problem since PIO data and DMA timings match and I also don't remember seeing devices which would allow S/MWDMA timings shorter than PIO timings.

Quoted 1 line

with UltraDMA 16-bit PIO timings aren't going to be changed from the defaults.

Bart

#24 lore raw
In reply to Bob Ham
Quoted 6 lines

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.

Should be fixed in the latest updates.