Re: AHCI + ST3160023AS + NCQ problems
On 10/30/07, Michael Tokarev [EMAIL PROTECTED] wrote: By the way, did you forget to remove a jumper on the drive (the only jumper installed by default) that limits drive usage to SATAI? ... ..etc. Try again without the jumper? Note that NCQ is NOT supported in SATAI mode, or there were some pre-standard implementations of it. In SATAII, NCQ is standard (well... more or less anyway ;) Huh? To my knowledge, the jumper should only limit the bus rate to 1.5Gbit/s, for compatibility with one or more chipsets. It shouldn't affect the command set supported by the device. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: pcmcia - spot slave decode flaws (for testing)
On 2/23/07, Alan [EMAIL PROTECTED] wrote: Code looks OK. Not applied due to for testing note. General comment: it might be nice to do this in the core, just as a sanity check for a variety of problems, past, present and future. We tried that with old IDE and all hell broke loose. Lots of virtual disk stuff and raid volumes have non-unique serial numbers. We even found a case of identically serial numbered Maxtor drives. It needs to stay in pcmcia, which is the only place we've seen the duplication. I don't think the maxtor drives actually had duplicate serial numbers. They were coming back as M000 or something like that to the limit of the strlen. It looked more like buffer corruption or something, and only happened with one or two people... --eric - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Implement the technote about promise/maxtor drives
On 2/15/07, Albert Lee [EMAIL PROTECTED] wrote: Some Maxtor drives have Maxtor and others have MAXTOR in the identify device data. If the slave is a MAXTOR one, the following code segment doesn't work. The 6L drive is a design brought over from Maxtor's purchase of Quantum, the 6Y is a Maxtor local design. Maybe we should check both Maxtor and MAXTOR? It will have to... or maybe not... Since I think Maxtor was the only vendor doing ATA133, maybe just limit slave port on those adapters to UDMA100? (Just checked newegg, and Hitachi lists theirs as ATA133, while Samsung list theirs as ATA133 compatible (default ATA100)) Were there enough other vendors doing ATA133 at the time the technote was written to know if other brands were also affected? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libata: reduce ATA command timeout to 7secs
On 2/2/07, Mark Lord [EMAIL PROTECTED] wrote: 7 seconds is not enough for current drives to report back. Adding another (8 seconds total) is enough, but I prefer to see a little margin there, so call it 10 seconds. If you're going to allow 30 seconds (or more) for a cache flush, you probably want to allow 30 seconds (or more) for any command that might implicitly cause a cache flush. Things like EXECUTE DEVICE DIAGNOSTICS, IDENTIFY DEVICE, NOP, STANDBY/IDLE IMMEDIATE, both soft and hard reset, most SMART commands, etc. In fact, my understanding is that many devices will flush their write caches to disk when receiving non-data commands, so those commands may take a while if they occur immediately following heavy write activity, even without errors being present. While sure, a reset should function fine being issued in the middle of a command, and bring the drive back to a ready state, I don't know if these assumptions about 7s vs 8s vs 10s are always going to be valid for disk drives purchased through distribution channels or in the generic PC market, as opposed to RAID edition or MaxLine or similar branding from other vendors, where the firmware may have been specifically optimized for quicker command completion, quicker status reporting and less exhaustive error recovery. Many linux users I assume are buying/borrowing/stealing cheap old gear from whatever source they can, and I don't want to unnecessarilly risk compounding the issue in their environments. --eric - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no DRQ after issuing MULTWRITE_EXT ?
On 2/1/07, Steven Scholz [EMAIL PROTECTED] wrote:
Hi all,
I am seeing kernel messages like
[ 1284.48] hda: status timeout: status=0xd0 { Busy }
[ 1284.48] ide: failed opcode was: unknown
[ 1284.48] hda: no DRQ after issuing MULTWRITE_EXT
[ 1284.49] ide0: unexpected interrupt, status=0x80, count=1
[ 1284.83] ide0: reset: success
with a 2.5 Seagate ST940813AM on my embedded ARM system (linux 2.6.14, no
IDE controller. HDD registers just memory mapped).
HDD is used in PIO4 with MultSect=16.
What exactly does that mean? Only that the HDD is to slow to answer this
request with 100ms (WAIT_DRQ=(HZ/10))?
And will the request issued again after the reset of the drive?
Some old posting mentions that disabling multi sector write would help.
But I did not find any references to why this would solve the problem.
Is it a bug of this special HDD? Or a kernel problem?
Do you see this on every multiblock PIO write? Or just occasionally?
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPA and failed opcode was: 0x37 ?
On 1/30/07, Steven Scholz [EMAIL PROTECTED] wrote:
I have connected HDD's A[2..0] to CPU's A[3..1] and do something like
for (i = IDE_DATA_OFFSET; i = IDE_STATUS_OFFSET; i++) {
hw.io_ports[i] = ide_virt_base + (i 1);
}
thus all HDD registers are accessed on a 16bit aligned address. Thus
ide_inb() should return the correct value.
And btw are things like identify driver use 8bit transfers?
How could one then explain
current capacity is 78140160 sectors would be 0x04A85300
native capacity is 185074430006016 sectors would be0xA852FFA85300
? First three bytes ok, then the other three bytes rubbish?
Steven
Maybe I am misunderstanding the issue, but the upper 3 bytes (and in
fact all the extended registers) of a 48-bit LBA address are found by
re-reading the taskfile registers after setting the HOB bit (bit 7) in
the device control register. If your FPGA is simulating a taskfile
for the generic driver to read, then your FPGA will need to perform
this access on the device to simulate the extended taskfile registers.
In the above log, your upper 3 bytes appear to be garbage.
This is documented in the description of the 48-bit Address Feature
Set in recent ATA specifications. Recent working draft
specifications are available from www.t13.org for anyone to browse and
download.
--eric
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPA and failed opcode was: 0x37 ?
On 1/30/07, Sergei Shtylyov [EMAIL PROTECTED] wrote: Steven Scholz wrote: How could one then explain current capacity is 78140160 sectors would be 0x04A85300 native capacity is 185074430006016 sectors would be0xA852FFA85300 ? First three bytes ok, then the other three bytes rubbish? Note that they're not complete garbage but equal the value of the lower 3 bytes minus 1. What is clear is that Read Native Max Address Ext command must be mistreating the HOB bit... :-) These commands all just use ide_raw_taskfile(), there's nothing special about READ NATIVE MAX ADDRESS EXT or SET MAX ADDRESS EXT. I still suspect the FPGA is misusing the HOB bit. The driver (for example) does a READ MAX ADDRESS EXT and stored that value (0x04A852FF is what is returned), then somehow only wrote to the lower 3 bytes of the LBA for the SET MAX command, the previous contents would shift into those upper bytes as shown. Maybe the FPGA is discarding the taskfile writes once the HOB bit is set? It wouldn't affect the READ NATIVE MAX ADDRESS EXT command being issued since the only the command register matters for that, but it would affect SET MAX ADDRESS EXT working properly. Without a device 137GB to test with, and without errors on the device, you might not see any odd behavior in normal usage. It's *really* unlikely the drive doesn't have a working taskfile. --eric - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] libata: dump full ATA firmware revision to dmesg
SCSI only supports a 4-character firmware revision string, while ATA
uses 8 characters. Since it can be useful for debugging drive/host
issues, and because not everyone has a working hdparm on their system,
dump the full ATA firmware revision into dmesg at drive detection.
Only affects ATA devices connected via libata, and not ATAPI (since
they likely use SCSI conventions anyway).
Sample output from my dmesg:
ata1.00: ATA-7, max UDMA/133, 488395055 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: ata1: Firmware Revision: 3.AAC
ata1.00: configured for UDMA/133
ata2.00: ATA-7, max UDMA/133, 195813072 sectors: LBA48 NCQ (depth 0/32)
ata2.00: ata2: dev 0 multi count 16
ata2.00: ata2: Firmware Revision: VA111910
ata2.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA ST3250820AS 3.AA PQ: 0 ANSI: 5
scsi 1:0:0:0: Direct-Access ATA Maxtor 6V100E0 VA11 PQ: 0 ANSI: 5
Signed-off-by: Eric D. Mudama [EMAIL PROTECTED]
---
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index a388a8d..7dc4dad 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1607,6 +1607,7 @@ int ata_dev_configure(struct ata_device *dev)
const u16 *id = dev-id;
unsigned int xfer_mask;
char revbuf[7]; /* XYZ-99\0 */
+ char fwrevbuf[9];
int rc;
if (!ata_dev_enabled(dev) ata_msg_info(ap)) {
@@ -1721,6 +1722,16 @@ int ata_dev_configure(struct ata_device *dev)
ap-id, dev-devno, dev-multi_count);
}
+ if (ata_msg_drv(ap) print_info) {
+ /* SCSI only uses 4-char revisions, dump full
8 chars from ATA */
+ ata_id_c_string(dev-id, fwrevbuf, ATA_ID_FW_REV_OFS,
+ sizeof(fwrevbuf));
+
+ ata_dev_printk(dev, KERN_INFO,
+ ata%u: Firmware Revision: %s\n,
+ ap-id, fwrevbuf);
+ }
+
dev-cdb_len = 16;
}
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] libata: dump full ATA firmware revision to dmesg
SCSI only supports a 4-character firmware revision string, while ATA
uses 8 characters. Record this firmware revision string into dmesg.
Signed-off-by: Eric D. Mudama [EMAIL PROTECTED]
---
Patch is against 2.6.20-rc6 pull via GIT. Resubmitting to (hopefully)
fix linewrap and bad formatting of the commit message.
This is useful for drive vendors debugging issues with ATA devices and
libata, since not everyone can easily run hdparm on their systems.
Sample output from my dmesg, showing the truncated firmware revisions:
ata1.00: ATA-7, max UDMA/133, 488395055 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: ata1: Firmware Revision: 3.AAC
ata1.00: configured for UDMA/133
ata2.00: ATA-7, max UDMA/133, 195813072 sectors: LBA48 NCQ (depth 0/32)
ata2.00: ata2: dev 0 multi count 16
ata2.00: ata2: Firmware Revision: VA111910
ata2.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA ST3250820AS 3.AA PQ: 0 ANSI: 5
scsi 1:0:0:0: Direct-Access ATA Maxtor 6V100E0 VA11 PQ: 0 ANSI: 5
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index a388a8d..7dc4dad 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1607,6 +1607,7 @@ int ata_dev_configure(struct ata_device *dev)
const u16 *id = dev-id;
unsigned int xfer_mask;
char revbuf[7]; /* XYZ-99\0 */
+ char fwrevbuf[9];
int rc;
if (!ata_dev_enabled(dev) ata_msg_info(ap)) {
@@ -1721,6 +1722,16 @@ int ata_dev_configure(struct ata_device *dev)
ap-id, dev-devno, dev-multi_count);
}
+ if (ata_msg_drv(ap) print_info) {
+ /* SCSI only uses 4-char revisions, dump full
8 chars from ATA */
+ ata_id_c_string(dev-id, fwrevbuf, ATA_ID_FW_REV_OFS,
+ sizeof(fwrevbuf));
+
+ ata_dev_printk(dev, KERN_INFO,
+ ata%u: Firmware Revision: %s\n,
+ ap-id, fwrevbuf);
+ }
+
dev-cdb_len = 16;
}
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] libata: rearrange dmesg info to add full ATA revision
Per Jeff's suggestion, this patch rearranges the info printed for ATA
drives into dmesg to add the full ATA firmware revision and model
information, while keeping the output to 2 lines.
Signed-off-by: Eric D. Mudama [EMAIL PROTECTED]
---
This extra information is helpful for debugging drive-related issues
on ATA drives connected with libata, especially when the user can't
easily run hdparm.
Diff is against 2.6.20-rc6 (roughly).
Here's a snippet of my new dmesg with this patch, showing the full and
truncated firmware revision information:
[ 44.559351] ata3: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 19
[ 44.559407] ata4: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 19
[ 44.559450] scsi2 : ata_piix
[ 44.723970] ata3.00: ATA-7: ST3250820AS, 3.AAC, max UDMA/133
[ 44.724012] ata3.00: 488395055 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 44.732057] ata3.00: configured for UDMA/133
[ 44.732099] scsi3 : ata_piix
[ 44.897435] ata4.00: ATA-7: Maxtor 6V100E0, VA111910, max UDMA/133
[ 44.897476] ata4.00: 195813072 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 44.909506] ata4.00: configured for UDMA/133
[ 44.909618] scsi 2:0:0:0: Direct-Access ATA ST3250820AS 3.AA
PQ: 0 ANSI: 5
[ 44.910500] scsi 3:0:0:0: Direct-Access ATA Maxtor 6V100E0 VA11
PQ: 0 ANSI: 5
libata-core.c | 46 ++
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index a388a8d..b8f7223 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1607,6 +1607,8 @@ int ata_dev_configure(struct ata_device *dev)
const u16 *id = dev-id;
unsigned int xfer_mask;
char revbuf[7]; /* XYZ-99\0 */
+ char fwrevbuf[9];
+ char modelbuf[41];
int rc;
if (!ata_dev_enabled(dev) ata_msg_info(ap)) {
@@ -1661,6 +1663,16 @@ int ata_dev_configure(struct ata_device *dev)
dev-n_sectors = ata_id_n_sectors(id);
+ /* SCSI only uses 4-char revisions, dump full 8 chars from ATA
*/
+ ata_id_c_string(dev-id, fwrevbuf, ATA_ID_FW_REV_OFS,
+ sizeof(fwrevbuf));
+
+ ata_id_c_string(dev-id, modelbuf, ATA_ID_PROD_OFS,
+ sizeof(modelbuf));
+
+ if (dev-id[59] 0x100)
+ dev-multi_count = dev-id[59] 0xff;
+
if (ata_id_has_lba(id)) {
const char *lba_desc;
char ncq_desc[20];
@@ -1680,13 +1692,18 @@ int ata_dev_configure(struct ata_device *dev)
ata_dev_config_ncq(dev, ncq_desc, sizeof(ncq_desc));
/* print device info to dmesg */
- if (ata_msg_drv(ap) print_info)
- ata_dev_printk(dev, KERN_INFO, %s,
- max %s, %Lu sectors: %s %s\n,
+ if (ata_msg_drv(ap) print_info) {
+ ata_dev_printk(dev, KERN_INFO,
+ %s: %s, %s, max %s\n,
revbuf,
- ata_mode_string(xfer_mask),
+ modelbuf, fwrevbuf,
+ ata_mode_string(xfer_mask));
+ ata_dev_printk(dev, KERN_INFO,
+ %Lu sectors, multi %u: %s %s\n,
(unsigned long long)dev-n_sectors,
+ dev-multi_count,
lba_desc, ncq_desc);
+ }
} else {
/* CHS */
@@ -1703,22 +1720,19 @@ int ata_dev_configure(struct ata_device *dev)
}
/* print device info to dmesg */
- if (ata_msg_drv(ap) print_info)
- ata_dev_printk(dev, KERN_INFO, %s,
- max %s, %Lu sectors: CHS %u/%u/%u\n,
+ if (ata_msg_drv(ap) print_info) {
+ ata_dev_printk(dev, KERN_INFO,
+ %s: %s, %s, max %s\n,
revbuf,
- ata_mode_string(xfer_mask),
+ modelbuf, fwrevbuf,
+ ata_mode_string(xfer_mask));
+ ata_dev_printk(dev, KERN_INFO,
+ %Lu sectors, multi %u, CHS %u/%u/%u\n,
(unsigned long long)dev-n_sectors,
+ dev-multi_count,
dev-cylinders, dev-heads
Re: ahci problems with sata disk.
On 1/16/07, Jeff Garzik [EMAIL PROTECTED] wrote: ISTR either Jens or Andrew ran some numbers, and found that there was little utility beyond 4 or 8 tags or so. Write cache is effectively queueing small writes already, so NCQ simply brings random read performance closer to writes. I know on the Maxtor drives with ~16MB of cache, they could do almost 200 ops/s at 7200RPM with their buffer granularity. Random reads were about 70 ops/s at a depth of 1, and 120 ops/s at a depth of 32. Every double of queue depth added another level of performance, and brings it closer to the implementation of cached writes (queued or unqueued). (infinite queue depth basically eliminates seek and rotate time, and brings you to your minimum settle criteria as your minimum operation time) It really has a lot of application dependence, but for the mixed random workloads, a 25-30% performance increase was common in our testing. Drives should be able to handle normal streaming workloads at identical performance, with or without queueing, since the patterns are so easy to detect. If done properly, queueing should never hurt performance. High queue depths will increase average latency of course, but shouldn't hurt overall performance. --eric NCQ mainly helps with multiple threads doing reads. Writes are largely asynchronous to the user already (except for fsync-style writes). You want to be able to stuff the disk's internal elevator with as many read requests as possible, because reads are very often synchronous -- most apps (1) read a block, (2) do something, (3) goto step #1. The kernel's elevator isn't much use in these cases. True. And internal to the drive, normal elevator is meh. There are other algorithms for scheduling that perform better. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Scary Intel SATA problem: frozen
On 11/28/06, Sergei Shtylyov [EMAIL PROTECTED] wrote: Hello. Mark Lord wrote: Bit #4, when actually implemented, is a rotational seek indicator, which can be used for timing purposes. Hm, I thought it was DSC (drive seek complete) set by the SEEK command completion, and it's always implemented. Didn't you mean IDX (bit 1, IIRC)? 0x50 is the standard, non queueing device is ready status. It used to have those special meanings, but they're pretty obsolete today as I understand it. 0x40 is used for queueing, because bit 4 was the service bit for PATA TCQ. But when BUSY (bit #7) is set, the rest are generally nonsense. Indeed... WBR, Sergei Typically, 0x80 as the busy state indicates the device is in POR reset. Once the firmware is up and running in the device, it often switches from 0x80 to 0xD0 during POR. 0xD0 is the busy state you'd get to if you were 0x50 and received a command, so this is reported typically after the device is up and running. 0x7F usually is hardware indicating nothing is attached to the port, and isn't supposed to infer a non-busy state. You're right, while not meaningful according to spec, you can derive some information from the reported status even when you're only supposed to look at one bit. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UDMA modes
we'd need to see the dmesg output I am sure On 8/16/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My Maxtor Hard Disk supports UDMA = 6 (133) How can I control BITS options in controller ? What's line command ? How can I verify controller is properly configured in my kernel ? -- Messaggio Originale -- Subject: Re: UDMA modes From: Erik Slagter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: linux-ide@vger.kernel.org Date: Tue, 16 Aug 2005 11:05:17 +0200 On Tue, 2005-08-16 at 09:02 +0200, [EMAIL PROTECTED] wrote: I have motherboard which supports DMA ATA 66/100/133 and I connect HD with new 80-wire cable. I have FC3 with Kernel 2.6.9 With hdparm -i /dev/hda I get: DMA modes: udma0 udma1 udma2 UDMA modes: udma0 udma1 *udma2 Why udma is 2 and not udma 5 ? Controller not explicitly supported by linux or not configured in the kernel? Controller needs BITS option? (see IDE config). Harddisk doesn't support udma2? Allegato: signature.asc __ TISCALI ADSL 1.25 MEGA Solo con Tiscali Adsl navighi senza limiti e telefoni senza canone Telecom a partire da 19,95 Euro/mese. Attivala entro il 31 agosto, il primo MESE รจ GRATIS! CLICCA QUI. http://abbonati.tiscali.it/adsl/sa/1e25flat_tc/ - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
