Serial ATA (SATA) for Linux status report

Editor's preface: This is clearly a first draft, only covering the basics. In order for this document to be effective, I request that users and developers send me (or post) their SATA driver questions and issues. I will do my best to address them here.

Serial ATA (SATA) for Linux
status report
Dec 3, 2003

Hardware support
================

Intel ICH5
----------
Summary: No TCQ. Looks like a PATA controller, but with a few added, non-standard SATA port controls.

libata driver status: Production, but see issue #2, #3.

drivers/ide driver status: Production, but see issue #1, #2.

Issue #1: Depending on BIOS settings, IDE driver may lock up computer when probing drives.

Issue #2: Excessive interrupts are seen in some configurations.

Issue #3: "Enhanced mode" or "SATA-only mode" may need to be set in BIOS.

Intel ICH6 ("AHCI")
-------------------
Summary: Per-device queues, full SATA control including hotplug and PM.

libata driver status: In development.

Promise
-------
Summary: Per-host queues on all controllers. Full SATA control including hotplug and PM on all but one controller.

libata driver status: Beta.

Silicon Image 3112
------------------
Summary: No TCQ. Looks like a PATA controller, but with full SATA control including hotplug and PM.

libata driver status: Alpha.

drivers/ide driver status: Production, but see issue #4.

Issue #4: Need to have the most recent fixes posted to lkml, for stable operation and full performance (where possible).

Broadcom/ServerWorks/Apple
--------------------------
Summary: Huge per-device queues, full SATA control including hotplug and PM.

libata driver status: Beta.

VIA
---
Summary: No TCQ. Looks like a PATA controller, but with full SATA control including hotplug and PM.

libata driver status: Beta.

Software support
================

Basic Serial ATA support
------------------------
The "ATA host state machine", the core of the entire driver, is considered production-stable.

The error handling is _very_ simple, but at this stage that is an advantage. Error handling code anywhere is inevitably both complex and sorely under-tested. libata error handling is intentionally simple.

Positives:  Easy to review and verify correctness.  Never data
corruption.  Negatives:  if an error occurs, libata will simply send

the error back the block layer. There are limited retries by the block layer, depending on the type of error, but there is never a bus reset.

Or in other words: "it's better to stop talking to the disk than compound existing problems with further problems."

As Serial ATA matures, and host- and device-side errata become apparent, the error handling will be slowly refined. I am planning to work with a few (kind!) disk vendors, to obtain special drives/firmwares that allow me to inject faults, and otherwise exercise error handling code.

Queueing support
----------------
Even though some SATA host controllers on the market already support command queueing (a.k.a. "TCQ"), libata does not yet support it.

However, libata was designed from the ground-up to support queueing, so I need only change a few lines of code, and write two functions, to enable this behavior.

Queueing will be enabled in libata soon, but to do so requires a long stretch of testing on a large variety of controllers and drives. This is very time-intensive, and is the largest part of this task.

Tangent: Host-based queueing and Native Command Queueing

Queueing is the process of sending multiple commands to a single device, without waiting for prior commands to finish. This increases performance and reduces latency. There are three types of queueing in the ATA world:

1) "legacy TCQ" -- some PATA devices support this. Just ignore it, it's going away.

2) "host-based TCQ" -- the host controller supports a queue of drive commands, whether or not the drive supports it.

3) "Native Command Queueing" -- both host and drive cooperate in the queueing and execution of drive commands. This should provide the highest performance and lowest latency of all three options.

#1 is support by drivers/ide _only_. libata will not support this. #2 will soon be supported by libata.
#3 will be supported by libata when hardware is available from drive manufacturers.

Hotplug support
---------------
All SATA is hotplug.

libata does not support hotplug... yet.

Power Management support
------------------------
Over and above the power management specified in the ATA/ATAPI specification, one can aggressively control the power consumption of SATA hosts, the SATA bus, and the SATA device.

<snip>

Hi jeff! :)

One question - with "including hotplug", does that mean some set hotplug standard? Reason I'm asking is, we have a few servers from SuperMicro, with a ICH5R S-ATA controller that claims it's supporting hotplug, but hotplug is not in your ICH5-summary.

PS, libata works great on those systems, good work!

Alas, there is no hotplug support in the ICH5 or ICH5-R SATA hardware.

One could argue there is "coldplug" support in that hardware -- disable the entire interface, including any active devices, then re-enable and re-scan -- but it's a bit of a hack. If there's enough demand, I could write some code for that. It would involve something like

	# /sbin/sata off
	{ plug in or remove a device }
	# /sbin/sata on

You really, really, really don't want to actually unplug a SATA drive while it's active, on ICH5 hardware.

Jeff

hi,

are there chipsets which support SATA hot plugging? afaik sata is supposed to be hotplugable.

TIA
Othmar Pasteka

_Most_ SATA chipsets support hotplugging. ICH5 is unique in that it does not.

Jeff

In article <[email protected]>,

Please. Several vendors now have 1U boxes with 2 swappable SATA drives, and many of those vendors (e.g. supermicro) use motherboards with the ICH5 SATA chipset.

We're about to buy a few too, and we intend to use the drivers in RAID0 mode. The ability to swap a drive without powering down the whole box is quite essential.

Mike.

In theroy the scsi driver allows you kill a drive, and do rescan by
echoing to /proc/scsi.scsi. I know it worked under 2.4 with sca drive on a hotswap backplane. This was over a year ago. So it may have been broken.

scsi.c:
* Usage: echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi
* with "0 1 2 3" replaced by your "Host Channel Id Lun".

/*
* Usage: echo "scsi remove-single-device 0 1 2 3" >/proc/scsi/scsi
* with "0 1 2 3" replaced by your "Host Channel Id Lun". *

PS- Yes I know says it isn't for hotswap, and that it's prebeta. This comment dates back to at least 2.2. It's worked for least 4 years.

There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory  <[email protected]>

Hmm. There is a backplane involved, that might change things a little.

Quoting the manual:
"A Serial ATA controller is incorporated into the 875P chipset to provide a two-port Serial ATA subsystem, which is RAID 0 and RAID 1 supported. The Serial ATA drives are hot-swappable units. Note: The operating system you use must have RAID support to enable the hot-swap capability and RAID function of the Serial ATA drives."

"The Serial ATA drives plug into a backplane that provides power, drive ID and bus termination. A RAID controller can be used with the backplane to provide data security. The operating system you use must have RAID support to enable the hot-swap capability of the Serial ATA drives."

The wording here is a little confusing, but hot-swap seems to work quite well with intels windows fakeraid-drivers, at least. One just pushes the "i'm going to pull you out now"-button on the tray, and pull the drive tray out. Maybe it triggers an event to the fakeraid-driver, wich then powers down the bus? black backplane-magic?

Anyways, REAL S-ATA hardware RAID controllers are pretty cheap over here nowadays..

[trimmed off linux-scsi]

How does it work on other hardware?

Justin

Just yank the cord :)

Jeff

No plan to add the so-called "raid" capabilities of the 82801EB ?

Same here, is support for the 3114 underway ? Saw a message from Andre Hedrick back in July saying he had something seemingly working, but there's no news since...

(Andre, no rant here, just a question. It's for personal use and I'm grateful you do that on your freetime).

Arnaud.

AFAIK the raid capabilities are entirely in software.

And Intel just wrote and posted this component. Look for "iswraid" in the linux-kernel archives.

Underway, but beyond that cannot comment :)

Jeff

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

as I was too impatient, I wrote a quick hack for it.
Now I can see my drives on the 3114 controller.
RAID does not seem to work but I can access my SATA drives in normal mode.

hdparm gives a 57 Mb/s output.
I had no error/crash/corruption, it appears to work correctly.

It works on 2.4.23 and 2.6.0-test11 with libata. basically, you just need to add the PCI id for 3114 just like 3112 in sata_sil.c, load the module and enjoy.
I presume 3112 and 3114 chips are mostly identical.

I have tested this on 2 Tyan motherboards with Sil 3114 inside

I can generate a patch in a few moments if you want it.

cheers,
Mik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0MN5yOYzc4nQ8j0RApGlAJ9WZxYY5wos+epXPsz4W/SPgOa7rQCfcKx1 lbblGOkp3DKKQUcRyN978us=
=KBJD
-----END PGP SIGNATURE-----

Yes, a tested patch would be great, thanks!

Jeff

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

here it is ;) (for 2.6.0-test11)
it includes patches in siimage.c but it did not work IIRC (lost interrupt). (don't compile siimage inside the kernel, it would not boot)

enjoy,

cheers,
Mik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0MlPyOYzc4nQ8j0RAtFpAJ4hemZoIMnFcBjBXYjGD/uCXJ3d/QCfbjT6 KigiRN0fY1PPveJIiJyKCdE=
=KemZ
-----END PGP SIGNATURE-----

diff -ru linux-2.6.0-test11.orig/drivers/ide/pci/siimage.c linux-2.6.0-test11/drivers/ide/pci/siimage.c
@@ -55,6 +55,7 @@
 	switch(pdev->device)
 	{
 		case PCI_DEVICE_ID_SII_3112:
+		case PCI_DEVICE_ID_SII_3114:
 		case PCI_DEVICE_ID_SII_1210SA:
 			return 1;
 		case PCI_DEVICE_ID_SII_680:

@@ -1178,6 +1179,7 @@
 static struct pci_device_id siimage_pci_tbl[] = {
 	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_680,  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_3112, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1},
+	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_3114, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1},
 	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_1210SA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 2},
 	{ 0, },
 };

diff -ru linux-2.6.0-test11.orig/drivers/ide/pci/siimage.h linux-2.6.0-test11/drivers/ide/pci/siimage.h
@@ -13,7 +13,7 @@
 #undef SIIMAGE_BUFFERED_TASKFILE
 #undef SIIMAGE_LARGE_DMA
 
-#define SII_DEBUG 0
+#define SII_DEBUG 1
 
 #if SII_DEBUG
 #define siiprintk(x...)	printk(x)

@@ -72,6 +72,18 @@
 		.extra		= 0,
 	},{	/* 2 */
 		.vendor		= PCI_VENDOR_ID_CMD,
+		.device		= PCI_DEVICE_ID_SII_3114,
+		.name		= "SiI3114 Serial ATA",
+		.init_chipset	= init_chipset_siimage,
+		.init_iops	= init_iops_siimage,
+		.init_hwif	= init_hwif_siimage,
+		.channels	= 2,
+		.autodma	= AUTODMA,
+		.enablebits	= {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
+		.bootable	= ON_BOARD,
+		.extra		= 0,
+	},{	/* 3 */
+		.vendor		= PCI_VENDOR_ID_CMD,
 		.device		= PCI_DEVICE_ID_SII_1210SA,
 		.name		= "Adaptec AAR-1210SA",
 		.init_chipset	= init_chipset_siimage,

diff -ru linux-2.6.0-test11.orig/drivers/scsi/Kconfig linux-2.6.0-test11/drivers/scsi/Kconfig
@@ -441,7 +441,7 @@
 
 config SCSI_SATA_SIL
 	tristate "Silicon Image SATA support"
-	depends on SCSI_SATA && PCI && BROKEN
+	depends on SCSI_SATA && PCI
 	help
 	  This option enables support for Silicon Image Serial ATA.
 

diff -ru linux-2.6.0-test11.orig/drivers/scsi/sata_sil.c linux-2.6.0-test11/drivers/scsi/sata_sil.c
@@ -39,6 +39,7 @@
 
 enum {
 	sil_3112		= 0,
+	sil_3114		= 1,
 
 	SIL_IDE0_TF		= 0x80,
 	SIL_IDE0_CTL		= 0x8A,

@@ -62,6 +63,7 @@
 
 static struct pci_device_id sil_pci_tbl[] = {
 	{ 0x1095, 0x3112, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sil_3112 },
+	{ 0x1095, 0x3114, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sil_3114 },
 	{ }	/* terminate list */
 };
 

@@ -119,6 +121,14 @@
 		.pio_mask	= 0x03,			/* pio3-4 */
 		.udma_mask	= 0x7f,			/* udma0-6; FIXME */
 		.port_ops	= &sil_ops,
+	}, /* sil_3114 */
+	{
+		.sht		= &sil_sht,
+		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+				  ATA_FLAG_SRST | ATA_FLAG_MMIO,
+		.pio_mask	= 0x03,			/* pio3-4 */
+		.udma_mask	= 0x7f,			/* udma0-6; FIXME */
+		.port_ops	= &sil_ops,
 	},
 };
 

diff -ru linux-2.6.0-test11.orig/include/linux/pci_ids.h linux-2.6.0-test11/include/linux/pci_ids.h
@@ -882,6 +882,7 @@
 
 #define PCI_DEVICE_ID_SII_680		0x0680
 #define PCI_DEVICE_ID_SII_3112		0x3112
+#define PCI_DEVICE_ID_SII_3114		0x3114
 #define PCI_DEVICE_ID_SII_1210SA	0x0240
 
 #define PCI_VENDOR_ID_VISION		0x1098

Your messages seem to be conflicting. Does this work or not or just enough to see messages? I am dealing with the same exact thing for the 3512 chipset.

Aron

ssh [email protected] cat /dev/brain | grep ^work:

Aron Rubin                       Member, Engineering Staff
Lockheed Martin                  E-Mail: [email protected]
Advanced Technology Laboratories Phone:  856.792.9865
3 Executive Campus               Fax:    856.792.9930
Cherry Hill, NJ USA 08002        Web:    http://www.atl.lmco.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

there are 2 drivers in the kernel for SATA drives.
first one is the IDE way in drivers/ide/pci/siimage.c (sata drives appears as hde,hdf etc ).
the second drive is in libata in drivers/scsi/sata_sil.c (sata drives appears as sda,sdb etc ...) (the one I use daily)

the attached patch makes _both_ drivers work (whereas the previous one made only the libata one working)

I have not yet tested if the 4 sata ports works. I think I need to change the "channels" setting to have support for all ports (at least 2 ports work for me). I will try that later.

Cheers,
Mik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/1hpiyOYzc4nQ8j0RAjGTAJsETf+ARzNoIEuHbrakP/6p/jb+hwCgifj0 f9SZw9X2/1i6sYTx72MpEcE=
=doIM
-----END PGP SIGNATURE-----

diff -u -r linux-2.6.0-test11.orig/drivers/ide/pci/siimage.c linux-2.6.0-test11/drivers/ide/pci/siimage.c
@@ -55,6 +55,7 @@
 	switch(pdev->device)
 	{
 		case PCI_DEVICE_ID_SII_3112:
+		case PCI_DEVICE_ID_SII_3114:
 		case PCI_DEVICE_ID_SII_1210SA:
 			return 1;
 		case PCI_DEVICE_ID_SII_680:

@@ -1178,7 +1179,8 @@
 static struct pci_device_id siimage_pci_tbl[] = {
 	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_680,  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_3112, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1},
-	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_1210SA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 2},
+	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_3114, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 2},
+	{ PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_SII_1210SA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 3},
 	{ 0, },
 };
 

diff -u -r linux-2.6.0-test11.orig/drivers/ide/pci/siimage.h linux-2.6.0-test11/drivers/ide/pci/siimage.h
@@ -13,7 +13,7 @@
 #undef SIIMAGE_BUFFERED_TASKFILE
 #undef SIIMAGE_LARGE_DMA
 
-#define SII_DEBUG 0
+#define SII_DEBUG 1
 
 #if SII_DEBUG
 #define siiprintk(x...)	printk(x)

@@ -72,6 +72,18 @@
 		.extra		= 0,
 	},{	/* 2 */
 		.vendor		= PCI_VENDOR_ID_CMD,
+		.device		= PCI_DEVICE_ID_SII_3114,
+		.name		= "SiI3114 Serial ATA",
+		.init_chipset	= init_chipset_siimage,
+		.init_iops	= init_iops_siimage,
+		.init_hwif	= init_hwif_siimage,
+		.channels	= 2,
+		.autodma	= AUTODMA,
+		.enablebits	= {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
+		.bootable	= ON_BOARD,
+		.extra		= 0,
+	},{	/* 3 */
+		.vendor		= PCI_VENDOR_ID_CMD,
 		.device		= PCI_DEVICE_ID_SII_1210SA,
 		.name		= "Adaptec AAR-1210SA",
 		.init_chipset	= init_chipset_siimage,

diff -u -r linux-2.6.0-test11.orig/drivers/scsi/Kconfig linux-2.6.0-test11/drivers/scsi/Kconfig
@@ -441,7 +441,7 @@
 
 config SCSI_SATA_SIL
 	tristate "Silicon Image SATA support"
-	depends on SCSI_SATA && PCI && BROKEN
+	depends on SCSI_SATA && PCI
 	help
 	  This option enables support for Silicon Image Serial ATA.
 

diff -u -r linux-2.6.0-test11.orig/drivers/scsi/sata_sil.c linux-2.6.0-test11/drivers/scsi/sata_sil.c
@@ -39,6 +39,7 @@
 
 enum {
 	sil_3112		= 0,
+	sil_3114		= 1,
 
 	SIL_IDE0_TF		= 0x80,
 	SIL_IDE0_CTL		= 0x8A,

@@ -62,6 +63,7 @@
 
 static struct pci_device_id sil_pci_tbl[] = {
 	{ 0x1095, 0x3112, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sil_3112 },
+	{ 0x1095, 0x3114, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sil_3114 },
 	{ }	/* terminate list */
 };
 

@@ -119,6 +121,14 @@
 		.pio_mask	= 0x03,			/* pio3-4 */
 		.udma_mask	= 0x7f,			/* udma0-6; FIXME */
 		.port_ops	= &sil_ops,
+	}, /* sil_3114 */
+	{
+		.sht		= &sil_sht,
+		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+				  ATA_FLAG_SRST | ATA_FLAG_MMIO,
+		.pio_mask	= 0x03,			/* pio3-4 */
+		.udma_mask	= 0x7f,			/* udma0-6; FIXME */
+		.port_ops	= &sil_ops,
 	},
 };
 

diff -u -r linux-2.6.0-test11.orig/include/linux/pci_ids.h linux-2.6.0-test11/include/linux/pci_ids.h
@@ -882,6 +882,7 @@
 
 #define PCI_DEVICE_ID_SII_680		0x0680
 #define PCI_DEVICE_ID_SII_3112		0x3112
+#define PCI_DEVICE_ID_SII_3114		0x3114
 #define PCI_DEVICE_ID_SII_1210SA	0x0240
 
 #define PCI_VENDOR_ID_VISION		0x1098

Great! Now I know it is really working.

I've already corrected your previous patch and included it in -bart1 patch:
http://www.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/broken-out/ide-siimage-sil3114.patch

Yes, I forgot to send you corrected patch, sorry. :-)

--bart

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

if anyone is able to tell me how to find the io address of the SATA ports I could make this patch support the 4 drives of Sil3114 (only the 2 first are working atm).
As I really don't know how to find this, I prefer ask to the kernel experts ;) Once I have this info, making the patch is a matter of a few minutes I think

I tried looking at lspci/scanpci outputs but could not really find any usefull informations recording io ports.

Cheers,
Mik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/2QbVyOYzc4nQ8j0RAhO/AJ9bm0gJ7uwGlKquhXaIYm1GMRBVWQCdGPwn wbQskwDqvS7PI54zTefPquM=
=p1UV
-----END PGP SIGNATURE-----

(hijacking this subthread, sorry)

Jeff, you mentioned in the status report "don't remove an operating disk from an ICH5, hotplug is not supported".

Does this mean hardware damage, or just serious libata/ICH5 confusion? I've got a six-disk server here with two disks on an ICH5 and four on an SATA150 TX4, and I really would like to be able to hot-replace a disk in case of a failure. If the ICH5 cannort support this, I'm going to have to get a 3ware card.

_Probably_ no hardware damage, but I do not know for sure. I do not it will likely lockup, and data corruption is also a possibility.

As I mentioned in another email, ICH5 hardware does not support hot removal. HOWEVER. If the OS driver is given sufficient notice, it can shut down the port, and the sysadmin may then unplug the SATA cable.

As a tangent, your TX4 hardware fully supports hotplug, but libata does not yet support it.

Jeff

Just a little warning:

I have got a situation where the kernel won't boot when probing for partition tables on SATA drives. I understand that this is probably not related to libsata in any way... but... here it goes:

system is UP AMD Opteron 244/debian/sid
gcc (GCC) 3.3.3 20031206 (prerelease) (Debian)
binutils: Version: 2.14.90.0.7-3
kernel 2.6.0-test11

when compiling new kernel on a kernel optimized for Opteron on an opteron machine, the kernel wont boot...

libata version 0.81 loaded.
sata_via version 0.11
ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 20
ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 20
ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003 88:203f
ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
ata1: dev 0 configured for UDMA/100
scsi0 : sata_via
ata2: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003 88:407f
ata2: dev 0 ATA, max UDMA/133, 72303840 sectors (lba48)
ata2: dev 0 configured for UDMA/133
scsi1 : sata_via

  Vendor: ATA       Model: WDC WD2500JD-00F  Rev: 0.81
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: WDC WD360GD-00FN  Rev: 0.81
  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) SCSI device sda: drive cache: write through
sda: sda1
^^^ hangs right here with DMA timeout

when compiling new kernel on a kernel optimized for Athlon on an opteron machine, the kernel boots ok
(same gcc, same binutils, same machine, just an athlon optimized kernel)

... the boot continues like this:
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) SCSI device sda: drive cache: write through
sda: sda1 sda2
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sdb: 72303840 512-byte hdwr sectors (37020 MB) SCSI device sdb: drive cache: write through
sdb: sdb1
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
mice: PS/2 mouse device common for all mice
... and so on

Happened after I remotely restarted quite important server, had to get up really early to workaround this :-)
[by compiling new opteron optimized kernel on an non opteron kernel... duh, could wood chuck chuck a wood if wood chuck chuck ....]

I have no idea what might be wrong...

Regards,
Petr

Has anyone gotten their hands on any Silicon Image 3124 hardware? It was announced 3 months ago and supports PCI-X plus it's designed to support whatever the final SATA 2.0 spec ends up being. Full NCQ support.

http://www.siliconimage.com/products/sii3124.asp

Hot-Plug seems like one of the most universally supported features. What will it take to get it working? And what will it take to get it working on 2.4? Is that a major feature we'll just have to wait for in libata?

I personally need hot-swap on production servers.

-ryan

I guess I'm seeing this problem. I'm trying to get my P4P800 motherboard with an ICH5 chipset working completely. So far I've been living without the cdrom or DVD players. I see lots of other posts on linux-kernel about the same problems:

Whenever I try to access the cdrom my system becomes unusable. Due to high interrupts, typically over 150k/s. I thought libata would help, but I don't understand how to use the PATA drive and the cdrom drives while I'm using it.

The situation is that I have two SATA drives, a PATA drive and two cdrom drives (actually one CD burner and one DVD drive). They are

Primary Master:   PATA Drive
Secondary Master: CD Burner
Secondary Slave:  DVD-Rom
SATA-1:           SATA Drive
SATA-2:           SATA Drive

I've tried 2.4.23pre4 (no libata), 2.6.1 (IDE drivers), and 2.6.1 (with scsi libata drivers) with the following results:

2.4.23pre4: as soon as the cdrom is touched I see bursts of 150k interrupts
per second and the system becomes unresponsive momentarily every few seconds.

2.6.1 with regular IDE drivers: same as above except the system feels
responsive except for disk i/o. I see printks of "Disabling interrupt #18" and all disk i/o freezes for a few seconds.

2.6.1 with scsi ata_piix driver: the SATA drives show up and work fine but the
PATA drive and the cdroms doesn't show up at all. This is true even when I compile with the CONFIG_IDE, CONFIG_BLK_DEV_IDE, and CONFIG_BLK_DEV_IDECD enabled.

greg

I have the same deal. My offer to send Jeff a P4P800 motherboard to test with is still open....

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

I have a ABIT IC7-G motherboard with the ICH5 chipset.
No reported problems with it. I would be happy to do some tests, just in case I have not actually noticed the problems.

hda=DVD-ROM
hdb=DVD writer
hdc=SATA Seagate Hard Disc 160 Gig.
hdd=Empty.

I do sometimes have problems during BIOS startup, with it not detecting the SATA hard disc, but pressing the reset button a few times fixes that.

Jan 14 01:01:17 new kernel: Uniform Multi-Platform E-IDE driver revision: 7.00alpha2
Jan 14 01:01:17 new kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Jan 14 01:01:17 new kernel: ICH5-SATA: IDE controller at PCI slot 0000:00:1f.2
Jan 14 01:01:17 new kernel: ICH5-SATA: chipset revision 2
Jan 14 01:01:17 new kernel: ICH5-SATA: not 100%% native mode: will probe irqs later
Jan 14 01:01:17 new kernel:     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Jan 14 01:01:17 new kernel:     ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
Jan 14 01:01:17 new kernel: hda: ATAPI DVD-ROM 16XMax, ATAPI CD/DVD-ROM drive
Jan 14 01:01:17 new kernel: hdb: OPTORITEDVD RW DD0203, ATAPI CD/DVD-ROM drive
Jan 14 01:01:17 new kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jan 14 01:01:17 new kernel: hdc: ST3160023AS, ATA DISK drive
Jan 14 01:01:17 new kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jan 14 01:01:17 new kernel: hdc: max request size: 1024KiB
Jan 14 01:01:17 new kernel: hdc: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(33)
Jan 14 01:01:17 new kernel:  /dev/ide/host0/bus1/target0/lun0: p1 p2 < p5 p6 p7 >

I'm pretty sure the "excessive interrupts" issue was successfully tracked down by Jon Burgess (thanks!). He found this post describing an ICH5 hardware issue,
http://www.mail-archive.com/[email protected]/msg58421.html

and he also submitted the attached patch.

I've been meaning to rewrite his patch to isolate it more to ata_piix, but in the meantime maybe folks could test this?

Jeff

@@ -2386,6 +2386,37 @@
 }
 
 /**
+ *	ata_chk_spurious_int - Check for spurious interrupts
+ *	@ap: port to which command is being issued
+ *
+ *	Examines the DMA status registers and clears
+ *      unexpected interrupts
+ *
+ *	LOCKING:
+ */
+static inline void ata_chk_spurious_int(struct ata_port *ap) {
+	int host_stat;
+	
+	if (ap->flags & ATA_FLAG_MMIO) {
+		void *mmio = (void *) ap->ioaddr.bmdma_addr;
+		host_stat = readb(mmio + ATA_DMA_STATUS);
+	} else
+		host_stat = inb(ap->ioaddr.bmdma_addr + ATA_DMA_STATUS);
+	
+	if ((host_stat & (ATA_DMA_INTR | ATA_DMA_ERR | ATA_DMA_ACTIVE)) == ATA_DMA_INTR) {
+		if (ap->flags & ATA_FLAG_MMIO) {
+			void *mmio = (void *) ap->ioaddr.bmdma_addr;
+			writeb(host_stat & ~ATA_DMA_ERR, mmio + ATA_DMA_STATUS);
+		} else
+			outb(host_stat & ~ATA_DMA_ERR, ap->ioaddr.bmdma_addr + ATA_DMA_STATUS);
+		
+		DPRINTK("ata%u: Caught spurious interrupt, status 0x%X\n", ap->id, host_stat);
+		udelay(1);
+	}
+}
+
+
+/**
  *	ata_interrupt -
  *	@irq:
  *	@dev_instance:

@@ -2417,6 +2448,7 @@
 			qc = ata_qc_from_tag(ap, ap->active_tag);
 			if (qc && ((qc->flags & ATA_QCFLAG_POLL) == 0))
 				handled += ata_host_intr(ap, qc);
+			ata_chk_spurious_int(ap);
 		}
 	}
 

Tried it on top of 2.4.25-pre4-libata1. I set the BIOS on my Asus P4P800 to Enhanced mode, and the kernel locked solid during boot while trying to clean /tmp.... Setting the BIOS back to Compatible mode allows my system to boot.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

I have an Asus P4C800-E Deluxe, with two drivers on the ICH5 sata controllers. It is a 3Ghz cpu using HT.

I use the normal PIIX ide drivers for the pata channels, and libata for the sata ones. I also use the vector based interrupts. Kernel is 2.6.1-bk4.

Anyhow, I do not think the interrupt count is _that_ high, as it shares with usb and network and I cannot complain of problems with cdrom, etc, but I decided to try the patch anyhow. It have some interesting results though. First, network stops responding after a few minutes of uptime (especially easy to reproduce if you have heavy network traffic), then for some reason you cannot start a new program/login/etc, but those running seems Ok, and lastly X becomes totally unresponsive (although alt-sysrq-b still do work).

--

 # cat /proc/interrupts
           CPU0       CPU1
  0:   29703539   29690292    IO-APIC-edge  timer
  2:          0          0          XT-PIC  cascade
  8:          2          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 14:        564        210    IO-APIC-edge  ide0
 15:          1          0    IO-APIC-edge  ide1
169:    1049180    1055746   IO-APIC-level  libata, uhci_hcd, eth0
177:      39519      37904   IO-APIC-level  Intel ICH5
185:    2521873    2494269   IO-APIC-level  uhci_hcd, uhci_hcd, nvidia
193:          0          0   IO-APIC-level  uhci_hcd
201:          0          0   IO-APIC-level  ehci_hcd
NMI:          0          0
LOC:   59387583   59387287
ERR:          0
MIS:          0
--

Martin Schlemmer

One possible workaround it to enable both PATA and SATA drivers (using libata) and pass "ide2=noprobe ide3=noprobe" to kernel at boot. More detailled answer can be found here : http://www.hentges.net/howtos/p4p800_deluxe.html
Regards,
Raphaël.

Raphael Rigo wrote:
...<ICH5problems snipped>...

I have pretty much the same setup he recommends in UPDATE except of
the "ide2=noprobe ide3=noprobe" kernel boot options, not sure why would that be needed but my system (interl D865PERL, cd burner, ide and sata disks) works OK without it.

erik

Hello all,

Am Don, 2004-01-15 um 01.08 schrieb Erik Steffl:

The "Update" section describes the setup which - after *weeks* of frustrating trail-and-error - managed to get things going.

Notice the unusual BIOS setting (Enhanced Mode - SATA only) which did the trick and enabled PATA *and* SATA.
You may want to try that if you haven't already.

The ideN=noprobe my indeed not be necessary . It was recommended by Jeff Garzik to me at some time IIRC. Kernel 2.6 does *not* need the noprobe stuff AFAICT.

FWIW my P4P800 Deluxe is working flawlessly with 4 P-ATA devices (2 HDs, a ZIP100 and a 48x Burner) and one SATA 160Gb HD.

I'm using 2.4.22-bk36 with matching libata patch so i'd think that any kernel 2.4.23+ will do the trick.

HTH and GL

Matthias Hentges 
Cologne / Germany

[www.hentges.net] -> PGP welcome, HTML tolerated
ICQ: 97 26 97 4   -> No files, no URL's

My OS: Debian Woody. Geek by Nature, Linux by Choice

Thank you!

That was the key thing I was missing. With this setting the PATA drives show up on /dev/hd{a,b,c,d} and the SATA drives show up on /dev/sd{a,b} (using ata_piix). And everything seems to work pretty well in 2.6.1.

I've only tried the PATA hard drive and reading from cdrom. I haven't tried burning cds or playing a dvd yet.

greg

I have intel D865PERL, three IDE HDs, one CD burner, one SATA disk,
using scsi ata, kernel 2.4.21-ac4 with libata5 patches (libata patches needed beacause SATA driver is over 133GB), seems to be working fine, I am not using CD burner very often but I didn't see any instability when I used it (read or burn CDs).

When I use cdparanoia to rip audio CDs the system is quite slow but
that was always the case (even with different MB, no SATA, different kernels etc.)

Using SATA disk as IDE disk caused the system to freeze during boot
(right after the HDs were detected)

erik

What about SMART capabilities? with sii3112 I had it, but with libata I cannot get any informations :/

Witold Kręcicki (adasi) adasi [at] culm.net
GPG key: 7AE20871
http://www.culm.net

Currently do not support random userland programs throwing random ATA commands at us... so no SMART support at present :) It's coming, though.

Jeff

On the note of SATA interfaced drives, is there a way to power them down?

I have recently attached my spare PATA drive with a converter and use it just for backups (mount, rsync, umount). I have these configured through SCSI (/dev/sda) with the 3112 2.6.1 support. hdparm comlains the drive is SCSI... is there a similar command to power it down?

thanks
Craig