All of lore.kernel.org
 help / color / mirror / Atom feed
* HPT372N not supported?
@ 2003-03-17 17:28 Henning Schroeder
  2003-03-18 16:06 ` Alan Cox
  0 siblings, 1 reply; 3+ messages in thread
From: Henning Schroeder @ 2003-03-17 17:28 UTC (permalink / raw)
  To: linux-kernel

Hello,

i recently bought a Tyan Trinity KT400 S2495 mainboard. (more info at
http://www.tyan.com/products/html/trinitykt400.html). It has an
onboard Highpoint RAID controller labelled "Highpoint HPT372N
0236K41N". To my surprise, Kernel 2.4.21-pre5 does not support this
chip. The relevant driver, linux/drivers/ide/pci/hpt366.c, does
support the HPT372, though.

Looking through the Highpoint Web Site, I found a downloadable
opensource driver (at
http://www.highpoint-tech.com/372drivers_down.htm). The revision
history said that starting with v1.31 (21Dec2002), the HPT372N IC is
supported. Great.

I downloaded, compiled and insmodŽed the driver
(http://www.highpoint-tech.com/hpt3xx-opensource-v131.tgz), which
failed. I then checked the PCI IDS and to my very surprise, the PCI ID
from my chip (1103:0009) does not match the one required by the
Highpoint driver.

Doing further research, nobody seems to know anything about the
1103:0009. I finally submitted the description myself to the Linux PCI
ID Repository (http://pciids.sourceforge.net/).

So i changed the highpoint driver to detect the HPT372N on my
motherboard (see diff below) and it finally works.

I donŽt like that solution very much, though, because the highpoint
driver uses the scsi subsystem. Looking through highpoints hpt.c file
I could not find very much differences in the way the HPT372N is
accessed from the HPT372-way. Maybe somebody (Andre Hedrick?) could
look through the code and integrate the HPT372N into
linux/drivers/ide/pci/hpt366.c? This feat is regrettably way beyound
my own programming capability.

I still wonder whether the HPT372N really is so new that it is not yet
listed anywhere. (It is even hard to find on the Highpoint Website).
And I wonder what the difference between HPT372N and HPT372 is.

I would love to hear about the current status of that chip. I do not
need the RAID capability, just the extra IDE ports.

Thank you for your time.

Henning

~~~ lspci output (cropped) ~~~~~~~~~~~~~~~~~~~
00:0e.0 RAID bus controller: Triones Technologies, Inc.: Unknown device 0009 (rev 01)
        Subsystem: Triones Technologies, Inc.: Unknown device 0001
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2000ns min, 2000ns max), cache line size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at c400 [size=8]
        Region 1: I/O ports at c800 [size=4]
        Region 2: I/O ports at cc00 [size=8]
        Region 3: I/O ports at d000 [size=4]
        Region 4: I/O ports at d400 [size=256]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-


~~~ cat /proc/pci output (cropped) ~~~~~~~~~~~~~~~~~~~
  Bus  0, device  14, function  0:
    RAID bus controller: PCI device 1103:0009 (Triones Technologies, Inc.) (rev 1).
      IRQ 11.
      Master Capable.  Latency=64.  Min Gnt=8.Max Lat=8.
      I/O at 0xc400 [0xc407].
      I/O at 0xc800 [0xc803].
      I/O at 0xcc00 [0xcc07].
      I/O at 0xd000 [0xd003].
      I/O at 0xd400 [0xd4ff].

~~~ highpoint driver diff ~~~~~~~~~~~~~~~~~~~
diff -u hpt3xx-opensource-v131/hpt.c hpt3xx-opensource-v131-new/hpt.c
--- hpt3xx-opensource-v131/hpt.c        Tue Dec 24 02:45:16 2002
+++ hpt3xx-opensource-v131-new/hpt.c    Mon Mar 17 01:07:53 2003
@@ -4571,6 +4571,20 @@
                if (hpt3xx_init(pAdap, pPciDev)==0)
                        hpt_adapters[NumAdapters++] = pAdap;
        }
+       /*
+        * search for HPT372N chip
+        */
+       pPciDev = NULL;
+       while ((pPciDev=pci_find_device(HPT372N_VENDORID, HPT372N_DEVICEID, pPciDev))){
+               if (NumAdapters>=MAX_ADAPTERS) break;
+               pAdap = (PHPT_ADAPTER)GLOBAL_DATA_ALLOC(sizeof(HPT_ADAPTER));
+               pci_read_config_byte(pPciDev, REG_RID, &rev);
+                       pAdap->chip_type = CHIP_TYPE_HPT372N;
+                       pAdap->name = CONTROLLER_NAME_HPT372N;
+               pAdap->num_buses = 2;
+               if (hpt3xx_init(pAdap, pPciDev)==0)
+                       hpt_adapters[NumAdapters++] = pAdap;
+       }

        if (NumAdapters) {
                /*
diff -u hpt3xx-opensource-v131/hptglb.h hpt3xx-opensource-v131-new/hptglb.h
--- hpt3xx-opensource-v131/hptglb.h     Mon Dec  9 04:18:42 2002
+++ hpt3xx-opensource-v131-new/hptglb.h Mon Mar 17 01:08:35 2003
@@ -676,6 +676,8 @@
 #define HPT370_DEVICEID 0x0004
 #define HPT372A_VENDORID 0x1103
 #define HPT372A_DEVICEID 0x0005
+#define HPT372N_VENDORID 0x1103
+#define HPT372N_DEVICEID 0x0009

 /*
  * 370-370A timing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Henning Schroeder, Dipl.-Psych.
mailto:schroeder@psychologie.uni-wuerzburg.de


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: HPT372N not supported?
  2003-03-17 17:28 Henning Schroeder
@ 2003-03-18 16:06 ` Alan Cox
  0 siblings, 0 replies; 3+ messages in thread
From: Alan Cox @ 2003-03-18 16:06 UTC (permalink / raw)
  To: Henning Schroeder; +Cc: Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

On Mon, 2003-03-17 at 17:28, Henning Schroeder wrote:
> I donŽt like that solution very much, though, because the highpoint
> driver uses the scsi subsystem. Looking through highpoints hpt.c file
> I could not find very much differences in the way the HPT372N is
> accessed from the HPT372-way. Maybe somebody (Andre Hedrick?) could
> look through the code and integrate the HPT372N into
> linux/drivers/ide/pci/hpt366.c? This feat is regrettably way beyound
> my own programming capability.

Try the patch attached below. The 372N doesn't seem to be that different
except that we have to use different pci timing thresholds. The patch
below isn't tested as I don't have a 372N.

> I would love to hear about the current status of that chip. I do not
> need the RAID capability, just the extra IDE ports.

hptraid should already support the raid bits



[-- Attachment #2: a1 --]
[-- Type: text/plain, Size: 11281 bytes --]

--- ../linux.21pre5/drivers/ide/pci/hpt366.c	2003-02-27 19:13:39.000000000 +0000
+++ drivers/ide/pci/hpt366.c	2003-03-18 15:56:34.000000000 +0000
@@ -1,5 +1,5 @@
 /*
- * linux/drivers/ide/pci/hpt366.c		Version 0.34	Sept 17, 2002
+ * linux/drivers/ide/pci/hpt366.c		Version 0.35	March 18, 2003
  *
  * Copyright (C) 1999-2002		Andre Hedrick <andre@linux-ide.org>
  * Portions Copyright (C) 2001	        Sun Microsystems, Inc.
@@ -9,6 +9,10 @@
  * donation of an ABit BP6 mainboard, processor, and memory acellerated
  * development and support.
  *
+ * Highpoint have their own driver (source except for the raid part)
+ * available from http://www.highpoint-tech.com/hpt3xx-opensource-v131.tgz
+ * This may be useful to anyone wanting to work on the mainstream hpt IDE.
+ *
  * Note that final HPT370 support was done by force extraction of GPL.
  *
  * - add function for getting/setting power status of drive
@@ -96,7 +100,10 @@
 		u8 c0, c1;
 
 		p += sprintf(p, "\nController: %d\n", i);
-		p += sprintf(p, "Chipset: HPT%s\n", chipset_nums[class_rev]);
+		if(class_rev < 9)
+			p += sprintf(p, "Chipset: HPT%s\n", chipset_nums[class_rev]);
+		else
+			p += sprintf(p, "Chipset: HPT revision %d\n", class_rev);
 		p += sprintf(p, "--------------- Primary Channel "
 				"--------------- Secondary Channel "
 				"--------------\n");
@@ -158,6 +165,13 @@
 }
 #endif  /* defined(DISPLAY_HPT366_TIMINGS) && defined(CONFIG_PROC_FS) */
 
+/*
+ *	This wants fixing so that we do everything not by classrev
+ *	(which breaks on the newest chips) but by creating an
+ *	enumeration of chip variants and using that
+ */
+ 
+
 static u32 hpt_revision (struct pci_dev *dev)
 {
 	u32 class_rev;
@@ -165,6 +179,9 @@
 	class_rev &= 0xff;
 
 	switch(dev->device) {
+		/* Remap new 372N onto 372 */
+		case PCI_DEVICE_ID_TTI_HPT372N:
+			class_rev = PCI_DEVICE_ID_TTI_HPT372; break;
 		case PCI_DEVICE_ID_TTI_HPT374:
 			class_rev = PCI_DEVICE_ID_TTI_HPT374; break;
 		case PCI_DEVICE_ID_TTI_HPT371:
@@ -214,6 +231,11 @@
 	return mode;
 }
 
+/*
+ *	Note for the future; the SATA hpt37x we must set
+ *	either PIO or UDMA modes 0,4,5
+ */
+ 
 static u8 hpt3xx_ratefilter (ide_drive_t *drive, u8 speed)
 {
 	struct pci_dev *dev	= HWIF(drive)->pci_dev;
@@ -386,7 +408,6 @@
 	u8 drive_fast	= 0, drive_pci = 0x40 + (drive->dn * 4);
 	u32 list_conf	= 0, drive_conf = 0;
 	u32 conf_mask	= (speed >= XFER_MW_DMA_0) ? 0xc0000000 : 0x30070000;
-
 	/*
 	 * Disable the "fast interrupt" prediction.
 	 * don't holdoff on interrupts. (== 0x01 despite what the docs say)
@@ -509,7 +530,7 @@
 
 	drive->init_speed = 0;
 
-	if (id && (id->capability & 1) && drive->autodma) {
+	if ((id->capability & 1) && drive->autodma) {
 		/* Consult the list of known "bad" drives */
 		if (hwif->ide_dma_bad_drive(drive))
 			goto fast_ata_pio;
@@ -684,14 +705,20 @@
 	pci_read_config_byte(dev, 0x59, &reg59h);
 	pci_read_config_byte(dev, state_reg, &regXXh);
 
-	if (state) {
-		(void) ide_do_reset(drive);
-		pci_write_config_byte(dev, state_reg, regXXh|0x80);
-		pci_write_config_byte(dev, 0x59, reg59h|reset);
-	} else {
-		pci_write_config_byte(dev, 0x59, reg59h & ~(reset));
-		pci_write_config_byte(dev, state_reg, regXXh & ~(0x80));
-		(void) ide_do_reset(drive);
+	switch(state)
+	{
+		case BUSSTATE_ON:
+			(void) ide_do_reset(drive);
+			pci_write_config_byte(dev, state_reg, regXXh|0x80);
+			pci_write_config_byte(dev, 0x59, reg59h|reset);
+			break;
+		case BUSSTATE_OFF:
+			pci_write_config_byte(dev, 0x59, reg59h & ~(reset));
+			pci_write_config_byte(dev, state_reg, regXXh & ~(0x80));
+			(void) ide_do_reset(drive);
+			break;
+		default:
+			return -EINVAL;
 	}
 	return 0;
 }
@@ -758,6 +785,8 @@
 		tri_reg |= TRISTATE_BIT;
 		bus_reg |= resetmask;
 		break;
+	default:
+		return -EINVAL;
 	}
 	pci_write_config_byte(dev, 0x59, bus_reg);
 	pci_write_config_word(dev, tristate, tri_reg);
@@ -771,72 +800,121 @@
 	u16 freq;
 	u32 pll;
 	u8 reg5bh;
-
+	u8 reg5ah;
+	unsigned long dmabase = pci_resource_start(dev, 4);
+	u8 did, rid;	
+	int is_372n = 0;
 #if 1
-	u8 reg5ah = 0;
 	pci_read_config_byte(dev, 0x5a, &reg5ah);
 	/* interrupt force enable */
 	pci_write_config_byte(dev, 0x5a, (reg5ah & ~0x10));
 #endif
 
+	did = inb(dmabase + 0x22);
+	rid = inb(dmabase + 0x28);
+	
+	if((did == 4 && rid == 6) || (did == 5 && rid > 1))
+		is_372n = 1;
 	/*
 	 * default to pci clock. make sure MA15/16 are set to output
-	 * to prevent drives having problems with 40-pin cables.
+	 * to prevent drives having problems with 40-pin cables. Needed
+	 * for some drives such as IBM-DTLA which will not enter ready
+	 * state on reset when PDIAG is a input.
+	 *
+	 * ToDo: should we set 0x21 when using PLL mode ?
 	 */
 	pci_write_config_byte(dev, 0x5b, 0x23);
 
 	/*
 	 * set up the PLL. we need to adjust it so that it's stable. 
 	 * freq = Tpll * 192 / Tpci
+	 *
+	 * Todo. For non x86 should probably check the dword is
+	 * set to 0xABCDExxx indicating the BIOS saved f_CNT
 	 */
 	pci_read_config_word(dev, 0x78, &freq);
 	freq &= 0x1FF;
-	if (freq < 0x9c) {
-		pll = F_LOW_PCI_33;
-		if (hpt_minimum_revision(dev,8))
-			pci_set_drvdata(dev, (void *) thirty_three_base_hpt374);
-		else if (hpt_minimum_revision(dev,5))
-			pci_set_drvdata(dev, (void *) thirty_three_base_hpt372);
-		else if (hpt_minimum_revision(dev,4))
-			pci_set_drvdata(dev, (void *) thirty_three_base_hpt370a);
+	
+	/*
+	 * The 372N uses different PCI clock information and has
+	 * some other complications
+	 *	On PCI33 timing we must clock switch
+	 *	On PCI66 timing we must NOT use the PCI clock
+	 *
+	 * Currently we always set up the PLL for the 372N
+	 */
+	 
+	if(is_372n)
+	{
+		printk(KERN_INFO "hpt: HPT372N detected, using 372N timing.\n");
+		if(freq < 0x55)
+			pll = F_LOW_PCI_33;
+		else if(freq < 0x70)
+			pll = F_LOW_PCI_40;
+		else if(freq < 0x7F)
+			pll = F_LOW_PCI_50;
 		else
-			pci_set_drvdata(dev, (void *) thirty_three_base_hpt370);
-		printk("HPT37X: using 33MHz PCI clock\n");
-	} else if (freq < 0xb0) {
-		pll = F_LOW_PCI_40;
-	} else if (freq < 0xc8) {
-		pll = F_LOW_PCI_50;
-		if (hpt_minimum_revision(dev,8))
-			return -EOPNOTSUPP;
-		else if (hpt_minimum_revision(dev,5))
-			pci_set_drvdata(dev, (void *) fifty_base_hpt372);
-		else if (hpt_minimum_revision(dev,4))
-			pci_set_drvdata(dev, (void *) fifty_base_hpt370a);
+			pll = F_LOW_PCI_66;
+			
+		/* We always use the pll not the PCI clock on 372N */
+	}
+	else
+	{
+		if(freq < 0x9C)
+			pll = F_LOW_PCI_33;
+		else if(freq < 0xb0)
+			pll = F_LOW_PCI_40;
+		else if(freq <0xc8)
+			pll = F_LOW_PCI_50;
 		else
-			pci_set_drvdata(dev, (void *) fifty_base_hpt370a);
-		printk("HPT37X: using 50MHz PCI clock\n");
-	} else {
-		pll = F_LOW_PCI_66;
-		if (hpt_minimum_revision(dev,8))
-		{
-			printk(KERN_ERR "HPT37x: 66MHz timings are not supported.\n");
-			return -EOPNOTSUPP;
+			pll = F_LOW_PCI_66;
+	
+		if (pll == F_LOW_PCI_33) {
+			if (hpt_minimum_revision(dev,8))
+				pci_set_drvdata(dev, (void *) thirty_three_base_hpt374);
+			else if (hpt_minimum_revision(dev,5))
+				pci_set_drvdata(dev, (void *) thirty_three_base_hpt372);
+			else if (hpt_minimum_revision(dev,4))
+				pci_set_drvdata(dev, (void *) thirty_three_base_hpt370a);
+			else
+				pci_set_drvdata(dev, (void *) thirty_three_base_hpt370);
+			printk("HPT37X: using 33MHz PCI clock\n");
+		} else if (pll == F_LOW_PCI_40) {
+		} else if (pll == F_LOW_PCI_50) {
+			if (hpt_minimum_revision(dev,8))
+				pci_set_drvdata(dev, NULL);
+			else if (hpt_minimum_revision(dev,5))
+				pci_set_drvdata(dev, (void *) fifty_base_hpt372);
+			else if (hpt_minimum_revision(dev,4))
+				pci_set_drvdata(dev, (void *) fifty_base_hpt370a);
+			else
+				pci_set_drvdata(dev, (void *) fifty_base_hpt370a);
+			printk("HPT37X: using 50MHz PCI clock\n");
+		} else {
+			if (hpt_minimum_revision(dev,8))
+			{
+				printk(KERN_ERR "HPT37x: 66MHz timings are not supported.\n");
+				pci_set_drvdata(dev, NULL);
+			}
+			else if (hpt_minimum_revision(dev,5))
+				pci_set_drvdata(dev, (void *) sixty_six_base_hpt372);
+			else if (hpt_minimum_revision(dev,4))
+				pci_set_drvdata(dev, (void *) sixty_six_base_hpt370a);
+			else
+				pci_set_drvdata(dev, (void *) sixty_six_base_hpt370);
+			printk("HPT37X: using 66MHz PCI clock\n");
 		}
-		else if (hpt_minimum_revision(dev,5))
-			pci_set_drvdata(dev, (void *) sixty_six_base_hpt372);
-		else if (hpt_minimum_revision(dev,4))
-			pci_set_drvdata(dev, (void *) sixty_six_base_hpt370a);
-		else
-			pci_set_drvdata(dev, (void *) sixty_six_base_hpt370);
-		printk("HPT37X: using 66MHz PCI clock\n");
 	}
-	
+			
 	/*
 	 * only try the pll if we don't have a table for the clock
 	 * speed that we're running at. NOTE: the internal PLL will
 	 * result in slow reads when using a 33MHz PCI clock. we also
 	 * don't like to use the PLL because it will cause glitches
 	 * on PRST/SRST when the HPT state engine gets reset.
+	 *
+	 * ToDo: Use 66MHz PLL when ATA133 devices are present on a
+	 * 372 device so we can get ATA133 support
 	 */
 	if (pci_get_drvdata(dev)) 
 		goto init_hpt37X_done;
@@ -923,7 +1001,7 @@
 	if (!pci_get_drvdata(dev))
 	{
 		printk(KERN_ERR "hpt366: unknown bus timing.\n");
-		return -EOPNOTSUPP;
+		pci_set_drvdata(dev, NULL);
 	}
 	return 0;
 }
@@ -1061,6 +1139,12 @@
 
 	if (!dmabase)
 		return;
+		
+	if(pci_get_drvdata(hwif->pci_dev) == NULL)
+	{
+		printk(KERN_WARNING "hpt: no known IDE timings, disabling DMA.\n");
+		return;
+	}
 
 	dma_old = hwif->INB(dmabase+2);
 
@@ -1131,6 +1215,12 @@
 	pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
 	class_rev &= 0xff;
 
+	/* New ident 372N reports revision 1. We could do the 
+	   io port based type identification instead perhaps (DID, RID) */
+	   
+	if(d->device == PCI_DEVICE_ID_TTI_HPT372N)
+		class_rev = 5;
+		
 	strcpy(d->name, chipset_names[class_rev]);
 
 	switch(class_rev) {
@@ -1190,6 +1280,7 @@
 	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT302, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 2},
 	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT371, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 3},
 	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT374, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 4},
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT372N, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 5},
 	{ 0, },
 };
 
--- ../linux.21pre5/drivers/ide/pci/hpt366.h	2003-02-27 19:13:39.000000000 +0000
+++ drivers/ide/pci/hpt366.h	2003-03-18 15:30:26.000000000 +0000
@@ -512,6 +512,20 @@
 		.enablebits	= {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
 		.bootable	= OFF_BOARD,
 		.extra		= 0
+	},{	/* 5 */
+		.vendor		= PCI_VENDOR_ID_TTI,
+		.device		= PCI_DEVICE_ID_TTI_HPT372N,
+		.name		= "HPT372N",
+		.init_setup	= init_setup_hpt37x,
+		.init_chipset	= init_chipset_hpt366,
+		.init_iops	= NULL,
+		.init_hwif	= init_hwif_hpt366,
+		.init_dma	= init_dma_hpt366,
+		.channels	= 2,	/* 4 */
+		.autodma	= AUTODMA,
+		.enablebits	= {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
+		.bootable	= OFF_BOARD,
+		.extra		= 0
 	},{
 		.vendor		= 0,
 		.device		= 0,

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: HPT372N not supported?
@ 2003-03-19 15:07 O.Sezer
  0 siblings, 0 replies; 3+ messages in thread
From: O.Sezer @ 2003-03-19 15:07 UTC (permalink / raw)
  To: linux-kernel

pci_ids.h also has to be patched; something like this one:

--- linux/include/linux/pci_ids.h.orig	2003-03-11 18:50:01
+++ linux/include/linux/pci_ids.h	2003-03-19 16:16:09
@@ -975,6 +975,7 @@
  #define PCI_DEVICE_ID_TTI_HPT372	0x0005
  #define PCI_DEVICE_ID_TTI_HPT302	0x0006
  #define PCI_DEVICE_ID_TTI_HPT371	0x0007
+#define PCI_DEVICE_ID_TTI_HPT372N	0x0009
  #define PCI_DEVICE_ID_TTI_HPT374	0x0008

  #define PCI_VENDOR_ID_VIA		0x1106

--
O.Sezer




"Alan Cox" wrote:

On Mon, 2003-03-17 at 17:28, Henning Schroeder wrote:
 > I don=C5=BDt like that solution very much, though, because the highpoint
 > driver uses the scsi subsystem. Looking through highpoints hpt.c file
 > I could not find very much differences in the way the HPT372N is
 > accessed from the HPT372-way. Maybe somebody (Andre Hedrick?) could
 > look through the code and integrate the HPT372N into
 > linux/drivers/ide/pci/hpt366.c? This feat is regrettably way beyound
 > my own programming capability.

Try the patch attached below. The 372N doesn't seem to be that different
except that we have to use different pci timing thresholds. The patch
below isn't tested as I don't have a 372N.

 > I would love to hear about the current status of that chip. I do not
 > need the RAID capability, just the extra IDE ports.

hptraid should already support the raid bits


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-03-19 15:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-19 15:07 HPT372N not supported? O.Sezer
  -- strict thread matches above, loose matches on Subject: below --
2003-03-17 17:28 Henning Schroeder
2003-03-18 16:06 ` Alan Cox

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.