Via SATA not working here

Via SATA not working here

[Michal 'hramrach' Suchanek]

Hello

I got a mainboard with a Via SATA controller, a Maxtor UATA 133 drive,
and an Asus SATA dongle (probably a Marvell chip).

When I was installing Linux the SATA controller got detected as IDE and
basically worked. I would see occasional messages about DMA timeout
while running from the install cd but the installation finished without
errors.

After building a 2.6.7 kernel I would get pretty much the same result.
I get a few messages about DMA timeout at startup and then it runs. But
I found it would eventually lock up with the hdd led shining steadily.

After inspecting the state of the drive with hdparm I found the DMA is
turned off, probably because the drive was reset after the DMA timeout.
The driver would then only allow setting udma2, saying udma 3/4/5 would
not work. But the DMA timeout would occur with udma2 mode too.

After searching the web I found I could enable the libata drivers to get
native support for the controller. But after booting the new kernel I get
a write error and the system would not boot. The write error is bogus
because the drive and controller works with the standard ide driver.

I cannot easily reproduce the messages of the libata driver because the
system would not boot. The message of the ide driver is pasted below.

I will probably change the cabling and put the primary drive on the
parallel ata controller so that the system runs better and more
experiments can be eventually done with the sata drivers.

Thanks

Michal Suchanek


Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0
VIA8237SATA: chipset revision 128
VIA8237SATA: 100% native mode on irq 185
    ide0: BM-DMA at 0xdc00-0xdc07, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 6Y200P0, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0xec00-0xec07,0xe802 on irq 185
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
    ide2: BM-DMA at 0xfc00-0xfc07, BIOS settings: hde:DMA, hdf:pio
    ide3: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdg:DMA, hdh:pio
hde: Pioneer DVD-ROM ATAPIModel DVD-120S, ATAPI CD/DVD-ROM drive
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
hdg: YAMAHA CRW-F1E, ATAPI CD/DVD-ROM drive
ide3 at 0x170-0x177,0x376 on irq 15
hda: max request size: 1024KiB
hda: 398297088 sectors (203928 MB) w/7936KiB Cache, CHS=24792/255/63

<snip>

hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status timeout: status=0xd0 { Busy }

hda: drive not ready for command
ide0: reset: success


lspci view of the controller:

00:0f.0 Class 0104: 1106:3149 (rev 80)
00:0f.0 RAID bus controller: VIA Technologies, Inc.: Unknown device 3149
(rev 80)
        Subsystem: Micro-star International Co Ltd: Unknown device 5901
        Flags: bus master, medium devsel, latency 32, IRQ 185
        I/O ports at ec00 [size=8]
        I/O ports at e800 [size=4]
        I/O ports at e400 [size=8]
        I/O ports at e000 [size=4]
        I/O ports at dc00 [size=16]
        I/O ports at d800 [size=256]
        Capabilities: [c0] Power Management version 2

00:0f.1 Class 0101: 1106:0571 (rev 06)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus
Master
IDE (rev 06) (prog-if 8a [Master SecP PriP])
        Subsystem: Micro-star International Co Ltd: Unknown device 5901
        Flags: bus master, medium devsel, latency 32, IRQ 185
        I/O ports at fc00 [size=16]
        Capabilities: [c0] Power Management version 2


hdparm view of the drive:

 Model=Maxtor 6Y200P0, FwRev=YAR41BW0, SerialNo=Y63G7CJE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5 udma6
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: (null):

Re: Via SATA not working here

[Brad Campbell]

Michal 'hramrach' Suchanek wrote:
> Hello
> 
> I got a mainboard with a Via SATA controller, a Maxtor UATA 133 drive,
> and an Asus SATA dongle (probably a Marvell chip).
> 
> When I was installing Linux the SATA controller got detected as IDE and
> basically worked. I would see occasional messages about DMA timeout
> while running from the install cd but the installation finished without
> errors.
> 
> After building a 2.6.7 kernel I would get pretty much the same result.
> I get a few messages about DMA timeout at startup and then it runs. But
> I found it would eventually lock up with the hdd led shining steadily.

Could you try it with a 2.6.5 kernel please? There were some changes made between 2.6.5 and 2.6.7 
that may well cause issues with HD's attached to dongles. There have been patches created for this 
by they have not yet made the mainstream kernel.

I'd be interested to see how that pans out.

Regards,
Brad

Re: Via SATA not working here

[Michal 'hramrach' Suchanek]

On Mon, Sep 13, 2004 at 08:23:23AM +0400, Brad Campbell wrote:
> Michal 'hramrach' Suchanek wrote:
> >Hello
> >
> >I found it would eventually lock up with the hdd led shining steadily.
I saw the lockup happen finally and I saw a stream of
hda: lost interrupt
I did not try to reproduce it with 2.6.5 because it takes hours of
compilig to cause the lockup.
> 
> Could you try it with a 2.6.5 kernel please? There were some changes made 
> between 2.6.5 and 2.6.7 that may well cause issues with HD's attached to 
> dongles. There have been patches created for this by they have not yet made 
> the mainstream kernel.
> 
> I'd be interested to see how that pans out.
With 2.6.5 I get the same results.

The libata error message:

ata1: DMA timeout, stat 0x0
ATA: abnormal status 0xD0 on prot 0xEC07
scsi0: ERROR on channel 0, id0, lin0, CDB: Write (10) 00 01 65 dc e7 00
00 42 00
Current sda: sense key Medium Error
Additional sense: Write Error - auto reallocation failed
end_request: I/O error, dev sda, sector 23452903
ATA: abnormal status 0xD0 on prot 0xEC07
ATA: abnormal status 0xD0 on prot 0xEC07
ATA: abnormal status 0xD0 on prot 0xEC07


Note that the 0xd0 is the same as the ide DMA timeout error.

Thanks

Michal Suchanek

Re: Via SATA not working here

[Eric Mudama]

On Tue, 14 Sep 2004 11:43:36 +0200, Michal 'hramrach' Suchanek
<hramrach@centrum.cz> wrote:
> With 2.6.5 I get the same results.
> 
> The libata error message:
> 
> ata1: DMA timeout, stat 0x0
> ATA: abnormal status 0xD0 on prot 0xEC07
> scsi0: ERROR on channel 0, id0, lin0, CDB: Write (10) 00 01 65 dc e7 00
> 00 42 00
> Current sda: sense key Medium Error
> Additional sense: Write Error - auto reallocation failed
> end_request: I/O error, dev sda, sector 23452903
> ATA: abnormal status 0xD0 on prot 0xEC07
> ATA: abnormal status 0xD0 on prot 0xEC07
> ATA: abnormal status 0xD0 on prot 0xEC07
> 
> Note that the 0xd0 is the same as the ide DMA timeout error.

Not sure how libata queried the additional sense: key/code/qual etc
from the drive, since it appears to have gotten a busy timeout.

FYI, 0xD0 is simply a 0x50 status (ready/seek complete) + the busy
bit, which is automatically set most by hardware upon receipt of a new
command.  In SATA, this is often set internally in a shadow task file
register, and has nothing to do with physical "registers" on the drive
itself.

Can someone quickie translate that CDB for me into its ATA command?

--eric

Re: Via SATA not working here

[Michal 'hramrach' Suchanek]

On Tue, Sep 14, 2004 at 09:03:19AM -0600, Eric Mudama wrote:
> On Tue, 14 Sep 2004 11:43:36 +0200, Michal 'hramrach' Suchanek
> <hramrach@centrum.cz> wrote:
> > With 2.6.5 I get the same results.
> > 
> > The libata error message:
> > 
> > ata1: DMA timeout, stat 0x0
> > ATA: abnormal status 0xD0 on prot 0xEC07
> > scsi0: ERROR on channel 0, id0, lin0, CDB: Write (10) 00 01 65 dc e7 00
> > 00 42 00
> > Current sda: sense key Medium Error
> > Additional sense: Write Error - auto reallocation failed
> > end_request: I/O error, dev sda, sector 23452903
> > ATA: abnormal status 0xD0 on prot 0xEC07
> > ATA: abnormal status 0xD0 on prot 0xEC07
> > ATA: abnormal status 0xD0 on prot 0xEC07
> > 
> > Note that the 0xd0 is the same as the ide DMA timeout error.
> 
> Not sure how libata queried the additional sense: key/code/qual etc
> from the drive, since it appears to have gotten a busy timeout.

imho it did not query it, it is simply bogus. afaict the drive does not
produce write errors so the code cannot query it whatever it does.
But i do not know anything about ata or the kernel ata drivers, I did
not even try to look.

Currently I have another drive attached to the sata dongle and neither
bios nor Linux can see it. Perhaps it is because  the drive is switched
to slave or it does not like the drive rack.

Thanks 

Michal Suchanek

Re: Via SATA not working here

[Jeff Garzik]

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

Michal 'hramrach' Suchanek wrote:
> imho it did not query it, it is simply bogus. afaict the drive does not
> produce write errors so the code cannot query it whatever it does.
> But i do not know anything about ata or the kernel ata drivers, I did
> not even try to look.
> 
> Currently I have another drive attached to the sata dongle and neither
> bios nor Linux can see it. Perhaps it is because  the drive is switched
> to slave or it does not like the drive rack.


ahhhhhh, that may be a clue.  If you are attaching a PATA drive via a 
bridge, that is very different from attaching a SATA drive, in terms of 
field behavior across the controller spectrum.

There are limitations on bridges.  Does Brad Campbell's patch (attached) 
work for you?

	Jeff


[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2939 bytes --]

diff -ur orig/linux-2.6.0/drivers/scsi/libata-core.c linux-2.6.9-rc1/drivers/scsi/libata-core.c
--- orig/linux-2.6.0/drivers/scsi/libata-core.c	2004-08-30 20:48:35.000000000 +0400
+++ linux-2.6.9-rc1/drivers/scsi/libata-core.c	2004-08-30 21:02:42.000000000 +0400
@@ -1128,6 +1128,37 @@
 	DPRINTK("EXIT, err\n");
 }
 
+
+static inline u8 ata_dev_knobble(struct ata_port *ap)
+{
+	return ((ap->cbl == ATA_CBL_SATA) && (!ata_id_is_sata(ap->device)));
+}
+
+/**
+ * 	ata_dev_config - Run device specific handlers and check for
+ * 			 SATA->PATA bridges
+ * 	@ap: Bus 
+ * 	@i:  Device
+ *
+ * 	LOCKING:
+ */
+ 
+void ata_dev_config(struct ata_port *ap, unsigned int i)
+{
+	/* limit bridge transfers to udma5, 200 sectors */
+	if (ata_dev_knobble(ap)) {
+		printk(KERN_INFO "ata%u(%u): applying bridge limits\n",
+			ap->id, ap->device->devno);
+		ap->udma_mask &= ATA_UDMA5;
+		ap->host->max_sectors = ATA_MAX_SECTORS;
+		ap->host->hostt->max_sectors = ATA_MAX_SECTORS;
+		ap->device->flags |= ATA_DFLAG_LOCK_SECTORS;
+	}
+
+	if (ap->ops->dev_config)
+		ap->ops->dev_config(ap, &ap->device[i]);
+}
+
 /**
  *	ata_bus_probe - Reset and probe ATA bus
  *	@ap: Bus to probe
@@ -1150,8 +1181,7 @@
 		ata_dev_identify(ap, i);
 		if (ata_dev_present(&ap->device[i])) {
 			found = 1;
-			if (ap->ops->dev_config)
-				ap->ops->dev_config(ap, &ap->device[i]);
+			ata_dev_config(ap,i);
 		}
 	}
 
@@ -1226,7 +1256,7 @@
 		ata_port_disable(ap);
 		return;
 	}
-
+	ap->cbl = ATA_CBL_SATA;
 	ata_bus_reset(ap);
 }
 
@@ -3567,3 +3597,4 @@
 EXPORT_SYMBOL_GPL(ata_scsi_release);
 EXPORT_SYMBOL_GPL(ata_host_intr);
 EXPORT_SYMBOL_GPL(ata_dev_id_string);
+EXPORT_SYMBOL_GPL(ata_dev_config);
nly in linux-2.6.9-rc1/include: config
diff -ur orig/linux-2.6.0/include/linux/ata.h linux-2.6.9-rc1/include/linux/ata.h
--- orig/linux-2.6.0/include/linux/ata.h	2004-08-30 20:48:35.000000000 +0400
+++ linux-2.6.9-rc1/include/linux/ata.h	2004-08-30 18:42:41.000000000 +0400
@@ -218,6 +218,7 @@
 };
 
 #define ata_id_is_ata(dev)	(((dev)->id[0] & (1 << 15)) == 0)
+#define ata_id_is_sata(dev)	((dev)->id[93] == 0)
 #define ata_id_rahead_enabled(dev) ((dev)->id[85] & (1 << 6))
 #define ata_id_wcache_enabled(dev) ((dev)->id[85] & (1 << 5))
 #define ata_id_has_flush(dev) ((dev)->id[83] & (1 << 12))
diff -ur orig/linux-2.6.0/include/linux/libata.h linux-2.6.9-rc1/include/linux/libata.h
--- orig/linux-2.6.0/include/linux/libata.h	2004-08-30 20:48:35.000000000 +0400
+++ linux-2.6.9-rc1/include/linux/libata.h	2004-08-30 20:42:05.000000000 +0400
@@ -400,6 +400,7 @@
 		 unsigned int n_elem);
 extern void ata_dev_id_string(struct ata_device *dev, unsigned char *s,
 			      unsigned int ofs, unsigned int len);
+extern void ata_dev_config(struct ata_port *ap, unsigned int i);
 extern void ata_bmdma_setup_mmio (struct ata_queued_cmd *qc);
 extern void ata_bmdma_start_mmio (struct ata_queued_cmd *qc);
 extern void ata_bmdma_setup_pio (struct ata_queued_cmd *qc);

Re: Via SATA not working here

[Brad Campbell]

Jeff Garzik wrote:
> 
> ahhhhhh, that may be a clue.  If you are attaching a PATA drive via a 
> bridge, that is very different from attaching a SATA drive, in terms of 
> field behavior across the controller spectrum.
> 
> There are limitations on bridges.  Does Brad Campbell's patch (attached) 
> work for you?
> 

I doubt it, thats why I had him compile up and test on a 2.6.5 kernel :p(
Sounds like a similar but different incompatibility.


Brad

Re: Via SATA not working here

[Michal 'hramrach' Suchanek]

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

On Tue, Sep 14, 2004 at 11:57:35PM +0400, Brad Campbell wrote:
> Jeff Garzik wrote:
> >
> >ahhhhhh, that may be a clue.  If you are attaching a PATA drive via a 
> >bridge, that is very different from attaching a SATA drive, in terms of 
> >field behavior across the controller spectrum.
> >
> >There are limitations on bridges.  Does Brad Campbell's patch (attached) 
> >work for you?
> >
> 
> I doubt it, thats why I had him compile up and test on a 2.6.5 kernel :p(
> Sounds like a similar but different incompatibility.
> 
Hello again

I thought I replied to this but I do not see the reply nor is 2.6.10
working for me. 

Thanks for the patch, it works for me but I had to apply it manually to
the newer kernel. I am not sure I got it right - when I unload ide-scsi
I get a kernel panic but I did not try with an unpatched kernel.

Also I wonder why sata is using the scsi emulation? Is it so different
from pata?

When I used the driver with ide kernel interface hdparm and smartctl
worked on the drive. If dma worked too it would be fine. With the scsi
interface hdparm and smartctl are confused by the drive.

I'm sorry if the previous mail got lost somehow.

Thanks

Michal Suchanek

[-- Attachment #2: linux-2.6.10-sata-pata-adaptor.patch --]
[-- Type: text/plain, Size: 2939 bytes --]

diff -ur orig/linux-2.6.0/drivers/scsi/libata-core.c linux-2.6.9-rc1/drivers/scsi/libata-core.c
--- orig/linux-2.6.0/drivers/scsi/libata-core.c	2004-08-30 20:48:35.000000000 +0400
+++ linux-2.6.9-rc1/drivers/scsi/libata-core.c	2004-08-30 21:02:42.000000000 +0400
@@ -1128,6 +1128,37 @@
 	DPRINTK("EXIT, err\n");
 }
 
+
+static inline u8 ata_dev_knobble(struct ata_port *ap)
+{
+	return ((ap->cbl == ATA_CBL_SATA) && (!ata_id_is_sata(ap->device)));
+}
+
+/**
+ * 	ata_dev_config - Run device specific handlers and check for
+ * 			 SATA->PATA bridges
+ * 	@ap: Bus 
+ * 	@i:  Device
+ *
+ * 	LOCKING:
+ */
+ 
+void ata_dev_config(struct ata_port *ap, unsigned int i)
+{
+	/* limit bridge transfers to udma5, 200 sectors */
+	if (ata_dev_knobble(ap)) {
+		printk(KERN_INFO "ata%u(%u): applying bridge limits\n",
+			ap->id, ap->device->devno);
+		ap->udma_mask &= ATA_UDMA5;
+		ap->host->max_sectors = ATA_MAX_SECTORS;
+		ap->host->hostt->max_sectors = ATA_MAX_SECTORS;
+		ap->device->flags |= ATA_DFLAG_LOCK_SECTORS;
+	}
+
+	if (ap->ops->dev_config)
+		ap->ops->dev_config(ap, &ap->device[i]);
+}
+
 /**
  *	ata_bus_probe - Reset and probe ATA bus
  *	@ap: Bus to probe
@@ -1150,8 +1181,7 @@
 		ata_dev_identify(ap, i);
 		if (ata_dev_present(&ap->device[i])) {
 			found = 1;
-			if (ap->ops->dev_config)
-				ap->ops->dev_config(ap, &ap->device[i]);
+			ata_dev_config(ap,i);
 		}
 	}
 
@@ -1226,7 +1256,7 @@
 		ata_port_disable(ap);
 		return;
 	}
-
+	ap->cbl = ATA_CBL_SATA;
 	ata_bus_reset(ap);
 }
 
@@ -3567,3 +3597,4 @@
 EXPORT_SYMBOL_GPL(ata_scsi_release);
 EXPORT_SYMBOL_GPL(ata_host_intr);
 EXPORT_SYMBOL_GPL(ata_dev_id_string);
+EXPORT_SYMBOL_GPL(ata_dev_config);
nly in linux-2.6.9-rc1/include: config
diff -ur orig/linux-2.6.0/include/linux/ata.h linux-2.6.9-rc1/include/linux/ata.h
--- orig/linux-2.6.0/include/linux/ata.h	2004-08-30 20:48:35.000000000 +0400
+++ linux-2.6.9-rc1/include/linux/ata.h	2004-08-30 18:42:41.000000000 +0400
@@ -218,6 +218,7 @@
 };
 
 #define ata_id_is_ata(dev)	(((dev)->id[0] & (1 << 15)) == 0)
+#define ata_id_is_sata(dev)	((dev)->id[93] == 0)
 #define ata_id_rahead_enabled(dev) ((dev)->id[85] & (1 << 6))
 #define ata_id_wcache_enabled(dev) ((dev)->id[85] & (1 << 5))
 #define ata_id_has_flush(dev) ((dev)->id[83] & (1 << 12))
diff -ur orig/linux-2.6.0/include/linux/libata.h linux-2.6.9-rc1/include/linux/libata.h
--- orig/linux-2.6.0/include/linux/libata.h	2004-08-30 20:48:35.000000000 +0400
+++ linux-2.6.9-rc1/include/linux/libata.h	2004-08-30 20:42:05.000000000 +0400
@@ -400,6 +400,7 @@
 		 unsigned int n_elem);
 extern void ata_dev_id_string(struct ata_device *dev, unsigned char *s,
 			      unsigned int ofs, unsigned int len);
+extern void ata_dev_config(struct ata_port *ap, unsigned int i);
 extern void ata_bmdma_setup_mmio (struct ata_queued_cmd *qc);
 extern void ata_bmdma_start_mmio (struct ata_queued_cmd *qc);
 extern void ata_bmdma_setup_pio (struct ata_queued_cmd *qc);

Re: Via SATA not working here

[Stefan Smietanowski]

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

Michal 'hramrach' Suchanek wrote:
| On Tue, Sep 14, 2004 at 11:57:35PM +0400, Brad Campbell wrote:
|
|>Jeff Garzik wrote:
|>
|>>ahhhhhh, that may be a clue.  If you are attaching a PATA drive via a
|>>bridge, that is very different from attaching a SATA drive, in terms of
|>>field behavior across the controller spectrum.
|>>
|>>There are limitations on bridges.  Does Brad Campbell's patch (attached)
|>>work for you?
|>>
|>
|>I doubt it, thats why I had him compile up and test on a 2.6.5 kernel :p(
|>Sounds like a similar but different incompatibility.
|>
|
| Hello again
|
| I thought I replied to this but I do not see the reply nor is 2.6.10
| working for me.
|
| Thanks for the patch, it works for me but I had to apply it manually to
| the newer kernel. I am not sure I got it right - when I unload ide-scsi
| I get a kernel panic but I did not try with an unpatched kernel.
|
| Also I wonder why sata is using the scsi emulation? Is it so different
| from pata?

It is not using scsi emulation. It is using the scsi subsystem in
the linux kernel instead of the ide subsystem. More and more
drivers are being written for "libata". And less and less in this
is actually SATA specific anymore. That is why we are starting
to see drivers that drive both sata and pata (promise for instance
in the libata-dev tree). Also note that if I understand correctly
libata will ultimately not use the scsi subsystem but the block
subsystem (that doesn't really exist yet). The way I see it
libata is the new way to do it right, and in which you can fit
any pata and/or sata driver. My personal goal is when we can
have one name-space between scsi and [sp]ata but that's not
here yet with many drivers only existing for the old/normal
ide susbystem, but that might/will change.

// Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCBOdIBrn2kJu9P78RArDJAJ4+VOc7sG+CIIW3wznDfaHkPC7+KQCeJI46
O8AGbX8rvDgmmV0MjRh5tQo=
=Fu32
-----END PGP SIGNATURE-----

Re: Via SATA not working here

[Michal 'hramrach' Suchanek]

On Sat, Feb 05, 2005 at 04:33:29PM +0100, Stefan Smietanowski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> It is not using scsi emulation. It is using the scsi subsystem in
> the linux kernel instead of the ide subsystem. More and more
> drivers are being written for "libata". And less and less in this
> is actually SATA specific anymore. That is why we are starting
> to see drivers that drive both sata and pata (promise for instance
> in the libata-dev tree). Also note that if I understand correctly
> libata will ultimately not use the scsi subsystem but the block
> subsystem (that doesn't really exist yet). The way I see it
Thanks for explanation. Hopefully it will happen soon :)

> libata is the new way to do it right, and in which you can fit
> any pata and/or sata driver. My personal goal is when we can
> have one name-space between scsi and [sp]ata but that's not
> here yet with many drivers only existing for the old/normal
> ide susbystem, but that might/will change.
> 
That would be a good thing. Especially if cdrecord/smartctl/hdparm was
ported to it so that it could use all features of the drive
independently of the bus to which it is connected.

Thanks

Michal Suchanek

Via SATA already working here [was: not working]

[Michal 'hramrach' Suchanek]

On Tue, Sep 14, 2004 at 02:06:18PM -0400, Jeff Garzik wrote:
> Michal 'hramrach' Suchanek wrote:
> >imho it did not query it, it is simply bogus. afaict the drive does not
> >produce write errors so the code cannot query it whatever it does.
> >But i do not know anything about ata or the kernel ata drivers, I did
> >not even try to look.
> >
> >Currently I have another drive attached to the sata dongle and neither
> >bios nor Linux can see it. Perhaps it is because  the drive is switched
> >to slave or it does not like the drive rack.
The drive rack works, just the drive has to be master or cable select.
The weird thing is the driver would report there  is no drive on the
second channel but would not say anything about the first channel where
the drive is connected.
> 
> 
> ahhhhhh, that may be a clue.  If you are attaching a PATA drive via a 
> bridge, that is very different from attaching a SATA drive, in terms of 
> field behavior across the controller spectrum.
> 
> There are limitations on bridges.  Does Brad Campbell's patch (attached) 
> work for you?

Looks great!
I have just compiled my new kernel on the drive connected through sata
using the patched libata driver.

Thanks

Michal Suchanek