Re: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
On Dec 1 2007 06:26, Justin Piszcz wrote: I ran the following: dd if=/dev/zero of=/dev/sdc dd if=/dev/zero of=/dev/sdd dd if=/dev/zero of=/dev/sde (as it is always a very good idea to do this with any new disk) Why would you care about what's on the disk? fdisk, mkfs and the day-to-day operation will overwrite it _anyway_. (If you think the disk is not empty, you should look at it and copy off all usable warez beforehand :-) - 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: SAS v SATA interface performance
On Dec 1, 2007 2:43 AM, Richard Scobie [EMAIL PROTECTED] wrote: Alan Cox wrote: If you want really high performance use multiple drives, on multiple PCIE controllers. Just make sure your backup planning of raid 1+0 setup is done right as many drives means a lot more drive fails. Thanks again. For what it's worth, I shall be attempting this with SATA drives in a RAID 50 configuration - 2 x 8 drives, using md RAID and an 8 lane PCIe SAS HBA. I suspect many of us will be curious of the performance results. Also, if you have Port Multiplexers (PMPs) in use, that would be interesting to know. I don't even know if PMPs are supported via SAS controllers in 2.6.24 or not. ie. PMP support is new to 2.6.24 and only a few Sata controllers will have PMP support in 2.6.24. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com - 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] sata_mv: Fix broken Marvell 7042 support.
sata_mv: Fix broken Marvell 7042 support.
The Marvell 7042 chip is more or less the same as the 6042 internally,
but sports a PCIe bus. Despite having identical SATA cores, the 7042
does differ from its PCI bus counterparts in placment and layout of
certain bus related registers.
This patch fixes sata_mv to distinguish between the PCI bus registers
of earlier chips, and the PCIe bus registers of the 7042.
Specifically, move the offsets and bit patterns for the
PCI/PCIe interrupt cause/mask registers into the struct mv_host_priv,
as these values differ between the 6xxx and 7xxx series chips.
This fixes the driver to not access reserved PCI addresses,
and prevents the lockups reported in linux-2.6.24 with 7042 boards.
Also add a new PCI ID for the Highpoint 2300 7042-based board
that I'm using for testing this stuff here.
Tested with Marvell 6081 + 7042 chips, on x86 x86_64.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
Patch is agains 2.6.24-rc3-git5, and should go into 2.6.24.
--- old/drivers/ata/sata_mv.c 2007-12-01 11:48:28.0 -0500
+++ linux/drivers/ata/sata_mv.c 2007-12-01 12:06:30.0 -0500
@@ -164,10 +164,14 @@
MV_PCI_ERR_ATTRIBUTE= 0x1d48,
MV_PCI_ERR_COMMAND = 0x1d50,
- PCI_IRQ_CAUSE_OFS = 0x1d58,
- PCI_IRQ_MASK_OFS= 0x1d5c,
+ PCI_IRQ_CAUSE_OFS = 0x1d58,
+ PCI_IRQ_MASK_OFS= 0x1d5c,
PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
+ PCIE_IRQ_CAUSE_OFS = 0x1900,
+ PCIE_IRQ_MASK_OFS = 0x1910,
+ PCIE_UNMASK_ALL_IRQS= 0x70a,/* assorted bits */
+
HC_MAIN_IRQ_CAUSE_OFS = 0x1d60,
HC_MAIN_IRQ_MASK_OFS= 0x1d64,
PORT0_ERR = (1 0), /* shift by port # */
@@ -303,6 +307,7 @@
MV_HP_GEN_I = (1 6), /* Generation I: 50xx */
MV_HP_GEN_II= (1 7), /* Generation II: 60xx */
MV_HP_GEN_IIE = (1 8), /* Generation IIE: 6042/7042
*/
+ MV_HP_PCIE = (1 9), /* PCIe bus/regs: 7042 */
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 0), /* is EDMA engine enabled? */
@@ -388,7 +393,15 @@
u32 pre;
};
-struct mv_host_priv;
+struct mv_host_priv {
+ u32 hp_flags;
+ struct mv_port_signal signal[8];
+ const struct mv_hw_ops *ops;
+ u32 irq_cause_ofs;
+ u32 irq_mask_ofs;
+ u32 unmask_all_irqs;
+};
+
struct mv_hw_ops {
void (*phy_errata)(struct mv_host_priv *hpriv, void __iomem *mmio,
unsigned int port);
@@ -401,12 +414,6 @@
void (*reset_bus)(struct pci_dev *pdev, void __iomem *mmio);
};
-struct mv_host_priv {
- u32 hp_flags;
- struct mv_port_signal signal[8];
- const struct mv_hw_ops *ops;
-};
-
static void mv_irq_clear(struct ata_port *ap);
static int mv_scr_read(struct ata_port *ap, unsigned int sc_reg_in, u32 *val);
static int mv_scr_write(struct ata_port *ap, unsigned int sc_reg_in, u32 val);
@@ -631,11 +638,13 @@
/* Adaptec 1430SA */
{ PCI_VDEVICE(ADAPTEC2, 0x0243), chip_7042 },
- { PCI_VDEVICE(TTI, 0x2310), chip_7042 },
-
- /* add Marvell 7042 support */
+ /* Marvell 7042 support */
{ PCI_VDEVICE(MARVELL, 0x7042), chip_7042 },
+ /* Highpoint RocketRAID PCIe series */
+ { PCI_VDEVICE(TTI, 0x2300), chip_7042 },
+ { PCI_VDEVICE(TTI, 0x2310), chip_7042 },
+
{ } /* terminate list */
};
@@ -1648,13 +1657,14 @@
static void mv_pci_error(struct ata_host *host, void __iomem *mmio)
{
+ struct mv_host_priv *hpriv = host-private_data;
struct ata_port *ap;
struct ata_queued_cmd *qc;
struct ata_eh_info *ehi;
unsigned int i, err_mask, printed = 0;
u32 err_cause;
- err_cause = readl(mmio + PCI_IRQ_CAUSE_OFS);
+ err_cause = readl(mmio + hpriv-irq_cause_ofs);
dev_printk(KERN_ERR, host-dev, PCI ERROR; PCI IRQ cause=0x%08x\n,
err_cause);
@@ -1662,7 +1672,7 @@
DPRINTK(All regs @ PCI error\n);
mv_dump_all_regs(mmio, -1, to_pci_dev(host-dev));
- writelfl(0, mmio + PCI_IRQ_CAUSE_OFS);
+ writelfl(0, mmio + hpriv-irq_cause_ofs);
for (i = 0; i host-n_ports; i++) {
ap = host-ports[i];
@@ -1926,6 +1936,8 @@
#define ZERO(reg) writel(0, mmio + (reg))
static void mv_reset_pci_bus(struct pci_dev *pdev, void __iomem *mmio)
{
+ struct ata_host *host = dev_get_drvdata(pdev-dev);
+ struct mv_host_priv *hpriv = host-private_data;
u32 tmp;
tmp = readl(mmio + MV_PCI_MODE);
@@ -1937,8 +1949,8 @@
writel(0x000100ff, mmio + MV_PCI_XBAR_TMOUT);
ZERO(HC_MAIN_IRQ_MASK_OFS);
Re: [PATCH] sata_mv: Fix broken Marvell 7042 support.
On Sat, 01 Dec 2007 13:07:22 -0500 Mark Lord [EMAIL PROTECTED] wrote: sata_mv: Fix broken Marvell 7042 support. The Marvell 7042 chip is more or less the same as the 6042 internally, but sports a PCIe bus. Despite having identical SATA cores, the 7042 does differ from its PCI bus counterparts in placment and layout of certain bus related registers. This patch fixes sata_mv to distinguish between the PCI bus registers of earlier chips, and the PCIe bus registers of the 7042. Specifically, move the offsets and bit patterns for the PCI/PCIe interrupt cause/mask registers into the struct mv_host_priv, as these values differ between the 6xxx and 7xxx series chips. This fixes the driver to not access reserved PCI addresses, and prevents the lockups reported in linux-2.6.24 with 7042 boards. Also add a new PCI ID for the Highpoint 2300 7042-based board that I'm using for testing this stuff here. Tested with Marvell 6081 + 7042 chips, on x86 x86_64. Signed-off-by: Mark Lord [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] - 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: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
Jan Engelhardt wrote: On Dec 1 2007 06:26, Justin Piszcz wrote: I ran the following: dd if=/dev/zero of=/dev/sdc dd if=/dev/zero of=/dev/sdd dd if=/dev/zero of=/dev/sde (as it is always a very good idea to do this with any new disk) Why would you care about what's on the disk? fdisk, mkfs and the day-to-day operation will overwrite it _anyway_. (If you think the disk is not empty, you should look at it and copy off all usable warez beforehand :-) Do you not test your drive for minimum functionality before using them? Also, if you have the tools to check for relocated sectors before and after doing this, that's a good idea as well. S.M.A.R.T is your friend. And when writing /dev/zero to a drive, if it craps out you have less emotional attachment to the data. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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: SAS v SATA interface performance
Greg Freemyer wrote: Also, if you have Port Multiplexers (PMPs) in use, that would be interesting to know. I don't even know if PMPs are supported via SAS controllers in 2.6.24 or not. ie. PMP support is new to 2.6.24 and only a few Sata controllers will have PMP support in 2.6.24. No, port multipliers are not in use here, the technology that SAS uses is called port expansion. While I do not know much about the low level operational differences, from a performance perspective, this is my understanding. Port multiplication only permits one drive to be accessed at once, whereas port expansion allows multiple drives to be accessed simultaneously. Port expanders are selfcontained and do not require kernel support - the only kernel requirement, is support for the SAS HBA or RAID controller. See Xtore, Adaptec or Dell (MD1000), for suitable JBOD enclosures. Regards, Richard - 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: SAS v SATA interface performance
Richard Scobie wrote: Greg Freemyer wrote: Also, if you have Port Multiplexers (PMPs) in use, that would be interesting to know. I don't even know if PMPs are supported via SAS controllers in 2.6.24 or not. ie. PMP support is new to 2.6.24 and only a few Sata controllers will have PMP support in 2.6.24. No, port multipliers are not in use here, the technology that SAS uses is called port expansion. While I do not know much about the low level operational differences, from a performance perspective, this is my understanding. Port multiplication only permits one drive to be accessed at once, whereas port expansion allows multiple drives to be accessed simultaneously. .. SATA port multipliers (think, hub) permit multiple drives to be active simultaneously. -ml - 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: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
Justin Piszcz wrote: I am putting a new machine together and I have dual raptor raid 1 for the root, which works just fine under all stress tests. Then I have the WD 750 GiB drive (not RE2, desktop ones for ~150-160 on sale now adays): I ran the following: dd if=/dev/zero of=/dev/sdc dd if=/dev/zero of=/dev/sdd dd if=/dev/zero of=/dev/sde (as it is always a very good idea to do this with any new disk) And sometime along the way(?) (i had gone to sleep and let it run), this occurred: [42880.680144] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x401 action 0x2 frozen [42880.680231] ata3.00: irq_stat 0x00400040, connection status changed [42880.680290] ata3.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 0 cdb 0x0 data 512 in [42880.680292] res 40/00:ac:d8:64:54/00:00:57:00:00/40 Emask 0x10 (ATA bus error) [42881.841899] ata3: soft resetting port [42885.966320] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [42915.919042] ata3.00: qc timeout (cmd 0xec) [42915.919094] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) [42915.919149] ata3.00: revalidation failed (errno=-5) [42915.919206] ata3: failed to recover some devices, retrying in 5 secs [42920.912458] ata3: hard resetting port [42926.411363] ata3: port is slow to respond, please be patient (Status 0x80) [42930.943080] ata3: COMRESET failed (errno=-16) [42930.943130] ata3: hard resetting port [42931.399628] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [42931.413523] ata3.00: configured for UDMA/133 [42931.413586] ata3: EH pending after completion, repeating EH (cnt=4) [42931.413655] ata3: EH complete [42931.413719] sd 2:0:0:0: [sdc] 1465149168 512-byte hardware sectors (750156 MB) [42931.413809] sd 2:0:0:0: [sdc] Write Protect is off [42931.413856] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [42931.413867] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Usually when I see this sort of thing with another box I have full of raptors, it was due to a bad raptor and I never saw it again after I replaced the disk that it happened on, but that was using the Intel P965 chipset. For this board, it is a Gigabyte GSP-P35-DS4 (Rev 2.0) and I have all of the drives (2 raptors, 3 750s connected to the Intel ICH9 Southbridge). I am going to do some further testing but does this indicate a bad drive? Bad cable? Bad connector? Could be any of the above. As you can see above, /dev/sdc stopped responding for a little bit and then the kernel reset the port. It looks like the first thing that happened is that the controller reported it lost the SATA link, and then the drive didn't respond until it was bashed with a few hard resets.. Why is this though? What is the likely root cause? Should I replace the drive? Obviously this is not normal and cannot be good at all, the idea is to put these drives in a RAID5 and if one is going to timeout that is going to cause the array to go degraded and thus be worthless in a raid5 configuration. Can anyone offer any insight here? Thank you, Justin. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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: SAS v SATA interface performance
Mark Lord wrote: SATA port multipliers (think, hub) permit multiple drives to be active simultaneously. Quite true, although the host controller could artificially limit this, giving the user a mistaken impression of their port multiplier being limited to one-command-per-N-drives. /nit pick :) Jeff - 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] sata_mv: fix compilation error when enabling DEBUG
Saeed Bishara wrote: From: Saeed Bishara [EMAIL PROTECTED] use sstatus instead status. Signed-off-by: Saeed Bishara [EMAIL PROTECTED] --- drivers/ata/sata_mv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c index a43f64d..97c3e11 100644 --- a/drivers/ata/sata_mv.c +++ b/drivers/ata/sata_mv.c @@ -2170,7 +2170,7 @@ static void mv_phy_reset(struct ata_port *ap, unsigned int *class, mv_scr_read(ap, SCR_ERROR, serror); mv_scr_read(ap, SCR_CONTROL, scontrol); DPRINTK(S-regs after ATA_RST: SStat 0x%08x SErr 0x%08x - SCtrl 0x%08x\n, status, serror, scontrol); + SCtrl 0x%08x\n, sstatus, serror, scontrol); applied #upstream-fixes - 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 1/1] Several fixes for the AVR32 PATA driver
Kristoffer Nyborg Gregertsen wrote: Several fixes for the AVR32 PATA driver: * Updated to use new AVR32 SMC timing API. This removes the need for magic constants in signal timing. * Removed the ATA_FLAG_PIO_POLLING, the driver should use interrupts. * Removed .port_disable and .irq_ack as these are no longer needed. * Improved some comments. Signed-off-by: Kristoffer Nyborg Gregertsen [EMAIL PROTECTED] applied #upstream-fixes - 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: report protocol and full CDB on error
Tejun Heo wrote: Protocol and CDB allocation size field are important in determining what went wrong with ATAPI commands. Report them on failure. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- This one is for #upstream-fixes. Thanks. nod, applied - 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: Peculiar out-of-sync boot log lines
Hi,
On Thursday 29 November 2007, Mark Lord wrote:
Nick Warne wrote:
Hi all,
2.6.23.9
I have noticed after applying Bart's patch to word93 blacklist my new
DVD drive:
http://lkml.org/lkml/2007/10/23/475
I see now in logs (look at the hdd line:
[dmesg]
hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63,
UDMA(66)
hdc: cache flushes not supported
hdc: hdc1
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache7hdd:
skipping word 93 validity check
, UDMA(66)
Uniform CD-ROM driver Revision: 3.20
7 ?? And the , UDMA(66) gets new lined, so in syslog it appears all
by itself:
...
That's a minor bug with the patch.
The code does this:
ide_dma_verbose::printk( ... 2048kB Cache);
eighty_ninty_three::printk(KERN_DEBUG %s: skipping word 93 validity
check\n);
ide_dma_verbose::printk(, UDMA(66)
Thanks for reporting/debugging it guys!
Something in there needs to insert a '\n' before the skipping word message.
Since it doesn't do that right now, the KERN_DEBUG string appears as 7
This seems like a good occasion to fix ide_dma_verbose() for good so... :)
[ patch is against current Linus tree so might not apply to 2.6.23.9 ]
[PATCH] ide: DMA reporting and validity checking fixes
* ide_xfer_verbose() fixups:
- beautify returned mode names
- fix PIO5 reporting
- make it return 'const char *'
* Change printk() level from KERN_DEBUG to KERN_INFO in ide_find_dma_mode().
* Add ide_id_dma_bug() helper based on ide_dma_verbose() to check for invalid
DMA info in identify block.
* Use ide_id_dma_bug() in ide_tune_dma() and ide_driveid_update().
As a result DMA won't be tuned or will be disabled after tuning if device
reports inconsistent info about enabled DMA mode (ide_dma_verbose() does the
same checks while the IDE device is probed by ide-{cd,disk} device driver).
* Since (id-capability 1) id-tDMA is a valid configuration handle
it correctly in ide_id_dma_bug().
* Remove no longer needed ide_dma_verbose().
This patch should fix the following problem with out-of-sync IDE messages
reported by Nick Warned:
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache7hdd:
skipping word 93 validity check
, UDMA(66)
and later debugged by Mark Lord to be caused by:
ide_dma_verbose()
printk( ... 2048kB Cache);
eighty_ninty_three()
printk(KERN_DEBUG %s: skipping word 93 validity check\n);
ide_dma_verbose()
printk(, UDMA(66)
Please note that as a result ide-{cd,disk} device drivers won't report the
DMA speed used but this is intended since now DMA mode being used is always
reported by IDE core code.
Cc: Nick Warne [EMAIL PROTECTED]
Cc: Mark Lord [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-cd.c |7 --
drivers/ide/ide-disk.c |5
drivers/ide/ide-dma.c | 57 -
drivers/ide/ide-iops.c |3 ++
drivers/ide/ide-lib.c | 55 ---
include/linux/ide.h|6 ++---
6 files changed, 51 insertions(+), 82 deletions(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -3049,12 +3049,7 @@ int ide_cdrom_probe_capabilities (ide_dr
else
printk( drive);
- printk(, %dkB Cache, be16_to_cpu(cap.buffer_size));
-
- if (drive-using_dma)
- ide_dma_verbose(drive);
-
- printk(\n);
+ printk(, %dkB Cache\n, be16_to_cpu(cap.buffer_size));
return nslots;
}
Index: b/drivers/ide/ide-disk.c
===
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -961,11 +961,8 @@ static void idedisk_setup (ide_drive_t *
if (id-buf_size)
printk ( w/%dKiB Cache, id-buf_size/2);
- printk(, CHS=%d/%d/%d,
+ printk(, CHS=%d/%d/%d\n,
drive-bios_cyl, drive-bios_head, drive-bios_sect);
- if (drive-using_dma)
- ide_dma_verbose(drive);
- printk(\n);
/* write cache enabled? */
if ((id-csfo 1) || (id-cfs_enable_1 (1 5)))
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -753,7 +753,7 @@ u8 ide_find_dma_mode(ide_drive_t *drive,
mode = XFER_MW_DMA_1;
}
- printk(KERN_DEBUG %s: %s mode selected\n, drive-name,
+ printk(KERN_INFO %s: %s mode selected\n, drive-name,
mode ? ide_xfer_verbose(mode) : no DMA);
return min(mode, req_mode);
@@ -772,6 +772,9 @@ static int ide_tune_dma(ide_drive_t *dri
if (__ide_dma_bad_drive(drive))
return 0;
+ if
Re: [PATCH 26/28] blk_end_request: changing ide-cd (take 3)
Hi,
On Saturday 01 December 2007, Kiyoshi Ueda wrote:
This patch converts ide-cd (cdrom_newpc_intr()) to use blk_end_request().
ide-cd (cdrom_newpc_intr()) has some tricky behaviors below which
need to use blk_end_request_callback().
Needs to:
1. call post_transform_command() to modify request contents
Seems like post_transform_command() call can be removed (patch below).
2. wait completing request until DRQ_STAT is cleared
Would be great if somebody convert cdrom_newpc_intr() to use scatterlists
also for PIO transfers (ide_pio_sector() in ide-taskfile.c should serve
as a good starting base to see how to do PIO transfers using scatterlists)
so we could get rid of partial request completions in cdrom_newpc_intr()
and just fully complete request when the transfer is done. Shouldn't be
difficult but I guess that we can live with blk_end_request_callback() for
the time being...
after end_that_request_first() and before end_that_request_last().
As for the second one, ide-cd will wait for the interrupt from device.
So blk_end_request_callback() has to return without completing request
even if no leftover in the request.
ide-cd uses a dummy callback function, which just returns value '1',
to tell blk_end_request_callback() about that.
Signed-off-by: Kiyoshi Ueda [EMAIL PROTECTED]
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
[PATCH] ide-cd: remove dead post_transform_command()
post_transform_command() call in cdrom_newpc_intr() has no effect because
it is done after the request has already been fully completed (rq-bio and
rq-data are always NULL). It was verified to be true regardless whether
INQUIRY command is using DMA or PIO to transfer data (by using modified
Tejun Heo's test-shortsg.c utility and adding a few printk()-s to ide-cd).
This was uncovered thanks to the blk_end_request: full I/O completion
handler (take 3) patch series from Kiyoshi Ueda.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: Kiyoshi Ueda [EMAIL PROTECTED]
Cc: Jun'ichi Nomura [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
Kiyoshi: please rebase your patch on top of this one (I'll send
it to Linus in the next IDE update), should make your patch a bit
simpler.
Tejun: you had really good timing with posting test-shortsg.c
(it saved me some time coding user-space SG_IO tester), thanks!
drivers/ide/ide-cd.c | 28
1 file changed, 28 deletions(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1650,31 +1650,6 @@ static int cdrom_write_check_ireason(ide
return 1;
}
-static void post_transform_command(struct request *req)
-{
- u8 *c = req-cmd;
- char *ibuf;
-
- if (!blk_pc_request(req))
- return;
-
- if (req-bio)
- ibuf = bio_data(req-bio);
- else
- ibuf = req-data;
-
- if (!ibuf)
- return;
-
- /*
-* set ansi-revision and response data as atapi
-*/
- if (c[0] == GPCMD_INQUIRY) {
- ibuf[2] |= 2;
- ibuf[3] = (ibuf[3] 0xf0) | 2;
- }
-}
-
typedef void (xfer_func_t)(ide_drive_t *, void *, u32);
/*
@@ -1810,9 +1785,6 @@ static ide_startstop_t cdrom_newpc_intr(
return ide_started;
end_request:
- if (!rq-data_len)
- post_transform_command(rq);
-
spin_lock_irqsave(ide_lock, flags);
blkdev_dequeue_request(rq);
end_that_request_last(rq, 1);
-
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 24/28] blk_end_request: changing ide normal caller (take 3)
On Saturday 01 December 2007, Kiyoshi Ueda wrote:
This patch converts normal parts of ide to use blk_end_request().
Signed-off-by: Kiyoshi Ueda [EMAIL PROTECTED]
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
---
drivers/ide/ide-cd.c |6 +++---
drivers/ide/ide-io.c | 17 ++---
2 files changed, 9 insertions(+), 14 deletions(-)
[...]
Index: 2.6.24-rc3-mm2/drivers/ide/ide-io.c
===
--- 2.6.24-rc3-mm2.orig/drivers/ide/ide-io.c
+++ 2.6.24-rc3-mm2/drivers/ide/ide-io.c
@@ -78,14 +78,9 @@ static int __ide_end_request(ide_drive_t
ide_dma_on(drive);
}
- if (!end_that_request_chunk(rq, uptodate, nr_bytes)) {
- add_disk_randomness(rq-rq_disk);
- if (dequeue) {
- if (!list_empty(rq-queuelist))
- blkdev_dequeue_request(rq);
+ if (!__blk_end_request(rq, uptodate, nr_bytes)) {
+ if (dequeue)
HWGROUP(drive)-rq = NULL;
- }
- end_that_request_last(rq, uptodate);
ret = 0;
}
Hmmm, this seems to change the old behavior (the request should
be dequeued from the queue only if 'dequeue' variable is set)
and AFAIR some error handling code (in ide-cd?) depends on the
old behavior so please revisit this patch.
Thanks,
Bart
-
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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: sata_mv: Fix broken Marvell 7042 support. The Marvell 7042 chip is more or less the same as the 6042 internally, but sports a PCIe bus. Despite having identical SATA cores, the 7042 does differ from its PCI bus counterparts in placment and layout of certain bus related registers. This patch fixes sata_mv to distinguish between the PCI bus registers of earlier chips, and the PCIe bus registers of the 7042. Specifically, move the offsets and bit patterns for the PCI/PCIe interrupt cause/mask registers into the struct mv_host_priv, as these values differ between the 6xxx and 7xxx series chips. This fixes the driver to not access reserved PCI addresses, and prevents the lockups reported in linux-2.6.24 with 7042 boards. Also add a new PCI ID for the Highpoint 2300 7042-based board that I'm using for testing this stuff here. Tested with Marvell 6081 + 7042 chips, on x86 x86_64. Signed-off-by: Mark Lord [EMAIL PROTECTED] applied #upstream-fixes - 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 #upstream-fixes] ata_piix: add more toshiba laptops to broken suspend list
Tejun Heo wrote: From: Peter Schwenke [EMAIL PROTECTED] Add more toshiba laptops to broken suspend list. This is from OSDL bugzilla bug 7780. tj: re-formatted patch and added description and SOB. Signed-off-by: Peter Schwenke [EMAIL PROTECTED] Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- This one is for #upstream-fixes -stable. I'll push it to Greg once it gets to Linus's tree. Thanks. drivers/ata/ata_piix.c | 28 1 file changed, 28 insertions(+) applied #upstream-fixes - 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 2/8] libata: implement protocol tests
Tejun Heo wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 5eb5983..8d5cd16 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5969,7 +5946,7 @@ void ata_qc_issue(struct ata_queued_cmd *qc)
*/
WARN_ON(ap-ops-error_handler ata_tag_valid(link-active_tag));
- if (qc-tf.protocol == ATA_PROT_NCQ) {
+ if (prot == ATA_PROT_NCQ) {
WARN_ON(link-sactive (1 qc-tag));
if (!link-sactive)
missed one?
-
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 4/8] libata: move ata_set_mode() to libata-eh.c
Tejun Heo wrote: Move ata_set_mode() to libata-eh.c. ata_set_mode() is surely an EH action and will be more tightly coupled with the rest of error handling. Move it to libata-eh.c. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Does this mean SET FEATURES - XFER MODE via SG_IO will be possible soon? ;-) - 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 8/8] libata: implement fast speed down for unverified data transfer mode
Tejun Heo wrote: It's very likely that the configured data transfer mode is the wrong one if device fails data transfers right after initial data transfer mode configuration (including NCQ on/off and xfermode). libata EH needs to speed down fast before upper layers give up on probing. This patch implement fast speed down rules to handle such cases better. Error occured while data transfer hasn't been verified trigger fast back-to-back speed down actions until data transfer works. This change will make cable mis-detection and other initial configuration problems corrected before partition scanning code gives up. Signed-off-by: Tejun Heo [EMAIL PROTECTED] I agree strongly. Good work! - 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 0/3] OF-platform PATA driver
Anton Vorontsov wrote:
Hi all,
Here is the second spin of the OF-platform PATA driver and
related patches.
Changes since RFC:
- nuked drivers/ata/pata_platform.h;
- powerpc bits: proper localbus node added.
Thanks for the previous review! This time I'm collecting acks,
don't be shy to give 'em generously. ;-)
if (ack_collected(PaulM))
push(ACK)
else {
/* do nothing */
}
-
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 1/8] libata: rearrange ATA_DFLAG_*
Tejun Heo wrote: Area for DFLAGs which are cleared on INIT is full. Extend it by 8 bits. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- include/linux/libata.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) applied 1-8 to #upstream - 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 12/12] pata_amd: update mode selection for NV PATAs
Tejun Heo wrote: Cable detection on NV PATA hosts isn't implemented and the CBLID- cable isn't wired according to the sepc either, so both host-side and generic drive-side cable detections are broken. Till now, nv_cable_detect() relied on peeking BIOS and ACPI configurations to upgrade to 80C but this often results in misdetection of 40C cable as 80C. Also, the original implementation was broken in that by the time BIOS configuration is read it has already been cleared by programming PIO0 during reset. This patch reimplements NV mode selection such that... * BIOS configuration value is stored during driver attach and restored on detach. * Cable type is fixed to ATA_CBL_PATA_IGN and mode selection is soley done by nv_mode_filter() which peeks both BIOS and ACPI configurations and filter accordingly. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Alan Cox [EMAIL PROTECTED] --- drivers/ata/pata_amd.c | 129 ++- 1 files changed, 93 insertions(+), 36 deletions(-) Yeah, I think this is a better way to do things long term. Thanks... - 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 RFC] sata_promise: make pdc_atapi_pkt() use values from qc-tf
Tejun Heo wrote: Make pdc_atapi_pkt() use values from qc-tf instead of creating its own. This is to ease future ATAPI handling changes. DONT APPLY YET --- Mikael, would this work? Values other than lbam and lbah remain the same. Does sata_promise have strict requirements for lbam and lbah? Thanks. drivers/ata/sata_promise.c | 34 +- 1 file changed, 13 insertions(+), 21 deletions(-) what was the outcome of this discussion? I haven't looked over the Promise datasheet nor checked my brain for details, hoping Mikael would do that for me ;-) - 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] ata: ahci: Enclosure Management via LED rev2
Kristen Carlson Accardi wrote: Enclosure Management via LED This patch implements Enclosure Management via the LED protocol as specified in AHCI specification. Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED] --- This revision makes the change to the comment requested by Mark Lord, fixes some bugs in the bit shifting for writing the new led state, and implements a show function so that led status can be read as well as written. Overall looks pretty good, from a technical review perspective. Two worries: 1) exporting ata_scsi_find_dev(), and assuming a scsi device is attached. the latter can be fixed by a !NULL check (and should be), but its a bit of a layering violation since long term we want to make the SCSI simulator optional for all ATA devices. 2) vaguely related to #1, I'm not so sure the attributes should be implemented directly in ahci. if this __or something like it__ appears on non-Intel hardware, the code should be somewhere more generic. - 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
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 28 +++
drivers/ata/libata-core.c |8 +++--
drivers/ata/libata-eh.c | 42 +++--
drivers/ata/pata_at32.c | 61 +++---
drivers/ata/pata_bf54x.c |7 +
drivers/ata/sata_mv.c | 64 ++--
6 files changed, 149 insertions(+), 61 deletions(-)
Alan Cox (1):
libata: Fix early use of port printk. (Was Re: ata4294967295: failed to
start port (errno=-19))
Kristoffer Nyborg Gregertsen (1):
Several fixes for the AVR32 PATA driver
Mark Lord (1):
sata_mv: Fix broken Marvell 7042 support.
Peter Missel (1):
libata: More IVB horkage from TSST
Peter Schwenke (1):
ata_piix: add more toshiba laptops to broken suspend list
Saeed Bishara (1):
sata_mv: fix compilation error when enabling DEBUG
Tejun Heo (1):
libata: report protocol and full CDB on error
sonic zhang (1):
Set proper ATA UDMA mode for bf548 according to system clock.
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 483269d..b538e1d 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -967,6 +967,13 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = TECRA M3,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, Tecra M3),
+ },
+ },
+ {
.ident = TECRA M5,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
@@ -981,6 +988,20 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = TECRA A8,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, TECRA A8),
+ },
+ },
+ {
+ .ident = Satellite R25,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, Satellite R25),
+ },
+ },
+ {
.ident = Satellite U200,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
@@ -988,6 +1009,13 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = Satellite U200,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, SATELLITE U200),
+ },
+ },
+ {
.ident = Satellite Pro U200,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 33f0627..b514a80 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4185,6 +4185,9 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Devices which get the IVB wrong */
{ QUANTUM FIREBALLlct10 05, A03.0900, ATA_HORKAGE_IVB, },
{ TSSTcorp CDDVDW SH-S202J, SB00, ATA_HORKAGE_IVB, },
+ { TSSTcorp CDDVDW SH-S202J, SB01, ATA_HORKAGE_IVB, },
+ { TSSTcorp CDDVDW SH-S202N, SB00, ATA_HORKAGE_IVB, },
+ { TSSTcorp CDDVDW SH-S202N, SB01, ATA_HORKAGE_IVB, },
/* End Marker */
{ }
@@ -6964,12 +6967,11 @@ int ata_host_start(struct ata_host *host)
if (ap-ops-port_start) {
rc = ap-ops-port_start(ap);
if (rc) {
- ata_port_printk(ap, KERN_ERR, failed to
- start port (errno=%d)\n, rc);
+ if (rc != -ENODEV)
+ dev_printk(KERN_ERR, host-dev, failed
to start port %d (errno=%d)\n, i, rc);
goto err_out;
}
}
-
ata_eh_freeze_port(ap);
}
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 0dac69d..e6605f0 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1850,30 +1850,54 @@ static void ata_eh_link_report(struct ata_link *link)
ehc-i.serror SERR_DEV_XCHG ? DevExch : );
for (tag = 0; tag
Re: [PATCH 04/12] libata: kill ata_id_to_dma_mode()
Tejun Heo wrote: ata_id_to_dma_mode() isn't quite generic. The function is basically privately implemented ata_id_xfermask() combined with hardcoded mode printing and configuration which are specific to ata_generic. Kill the function and open code it in generic_set_mode() using generic xfermode handling functions. Signed-off-by: Tejun Heo [EMAIL PROTECTED] [responding to Alan's objection, and subsequent thread] Yeah, it's a matter of taste. I applied, figuring in for a dime in for a dozen :) I'm not thrilled with all these fine-grained exports of timing tables and mode mask functions. I applied the patches, but I would really like to hide more of these details away from LLD [if possible, the obvious disclaimed...] Jeff - 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: Peculiar out-of-sync boot log lines
On Sat, 1 Dec 2007 22:59:35 +0100 Bartlomiej Zolnierkiewicz wrote:
Thanks for reporting/debugging it guys!
Something in there needs to insert a '\n' before the skipping word
message.
Since it doesn't do that right now, the KERN_DEBUG string appears as 7
This seems like a good occasion to fix ide_dma_verbose() for good so... :)
[ patch is against current Linus tree so might not apply to 2.6.23.9 ]
[PATCH] ide: DMA reporting and validity checking fixes
* ide_xfer_verbose() fixups:
- beautify returned mode names
- fix PIO5 reporting
- make it return 'const char *'
* Change printk() level from KERN_DEBUG to KERN_INFO in ide_find_dma_mode().
* Add ide_id_dma_bug() helper based on ide_dma_verbose() to check for invalid
DMA info in identify block.
* Use ide_id_dma_bug() in ide_tune_dma() and ide_driveid_update().
As a result DMA won't be tuned or will be disabled after tuning if device
reports inconsistent info about enabled DMA mode (ide_dma_verbose() does the
same checks while the IDE device is probed by ide-{cd,disk} device driver).
* Since (id-capability 1) id-tDMA is a valid configuration handle
it correctly in ide_id_dma_bug().
* Remove no longer needed ide_dma_verbose().
This patch should fix the following problem with out-of-sync IDE messages
reported by Nick Warned:
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache7hdd:
skipping word 93 validity check
, UDMA(66)
and later debugged by Mark Lord to be caused by:
ide_dma_verbose()
printk( ... 2048kB Cache);
eighty_ninty_three()
printk(KERN_DEBUG %s: skipping word 93 validity check\n);
ide_dma_verbose()
printk(, UDMA(66)
Please note that as a result ide-{cd,disk} device drivers won't report the
DMA speed used but this is intended since now DMA mode being used is always
reported by IDE core code.
Cc: Nick Warne [EMAIL PROTECTED]
Cc: Mark Lord [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-cd.c |7 --
drivers/ide/ide-disk.c |5
drivers/ide/ide-dma.c | 57
-
drivers/ide/ide-iops.c |3 ++
drivers/ide/ide-lib.c | 55 ---
include/linux/ide.h|6 ++---
6 files changed, 51 insertions(+), 82 deletions(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -3049,12 +3049,7 @@ int ide_cdrom_probe_capabilities (ide_dr
else
printk( drive);
- printk(, %dkB Cache, be16_to_cpu(cap.buffer_size));
-
- if (drive-using_dma)
- ide_dma_verbose(drive);
-
- printk(\n);
+ printk(, %dkB Cache\n, be16_to_cpu(cap.buffer_size));
Use
printk(KERN_CONT ...
so that someone won't try to add another KERN_* facility level to it.
(same for other continued printk calls in this patch)
return nslots;
}
Index: b/drivers/ide/ide-disk.c
===
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -961,11 +961,8 @@ static void idedisk_setup (ide_drive_t *
if (id-buf_size)
printk ( w/%dKiB Cache, id-buf_size/2);
- printk(, CHS=%d/%d/%d,
+ printk(, CHS=%d/%d/%d\n,
Ditto.
drive-bios_cyl, drive-bios_head, drive-bios_sect);
- if (drive-using_dma)
- ide_dma_verbose(drive);
- printk(\n);
/* write cache enabled? */
if ((id-csfo 1) || (id-cfs_enable_1 (1 5)))
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1333,8 +1334,7 @@ static inline void ide_set_hwifdata (ide
hwif-hwif_data = data;
}
-/* ide-lib.c */
-extern char *ide_xfer_verbose(u8 xfer_rate);
+const char *ide_xfer_verbose(u8);
extern void ide_toggle_bounce(ide_drive_t *drive, int on);
extern int ide_set_xfer_rate(ide_drive_t *drive, u8 rate);
Ideally function prototypes would include variable names, not just
types, as a helpful hint to readers of them.
---
~Randy
The Linux kernel requires that any needed documentation accompany all
changes requiring said documentation -- part of the source-code patch
must apply to the Documentation/ directory. [...]
To sum up: No undocumented changes.
-- Donnie Berkholz engages in some wishful thinking
http://lwn.net/Articles/259470/ Quote of the Week
-
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 01/12] ata_generic: unindent loop in generic_set_mode()
Tejun Heo wrote: Unindent loop body in generic_set_mode(). This is to ease future change. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/ata_generic.c | 31 --- 1 files changed, 16 insertions(+), 15 deletions(-) applied 1-12 to #upstream, with comments - 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: SAS v SATA interface performance
Jeff Garzik wrote: Mark Lord wrote: SATA port multipliers (think, hub) permit multiple drives to be active simultaneously. Quite true, although the host controller could artificially limit this, giving the user a mistaken impression of their port multiplier being limited to one-command-per-N-drives. Interesting. I was basing my comments on what may well be a vested interest slanted paper - see the sidebar on page 2. http://www.xtore.com/Downloads/WhitePapers/SAS_SATAValue%20Whitepaper_final.pdf For the modest extra cost of a non-RAID SAS HBA and JBOD enclosure with SATA drives, over a port multiplied setup, there would seem to be some advantages. Or have I been taken in by the hype... :) Regards, Richard - 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: SAS v SATA interface performance
Richard Scobie wrote: Jeff Garzik wrote: Mark Lord wrote: SATA port multipliers (think, hub) permit multiple drives to be active simultaneously. Quite true, although the host controller could artificially limit this, giving the user a mistaken impression of their port multiplier being limited to one-command-per-N-drives. Interesting. I was basing my comments on what may well be a vested interest slanted paper - see the sidebar on page 2. http://www.xtore.com/Downloads/WhitePapers/SAS_SATAValue%20Whitepaper_final.pdf For the modest extra cost of a non-RAID SAS HBA and JBOD enclosure with SATA drives, over a port multiplied setup, there would seem to be some advantages. Or have I been taken in by the hype... :) .. Here's the hype part from that biased paper: Performance: Port Multipliers only support one active host connection at a time, signi cantly degrading e ective throughput. Each time communication is initiated with a drive time-consuming drive reset must occur. Data Integrity: PMs must close the connection to one drive to open a new one to another. When a connection is closed drive history (e.g., data source, destination drive, data command context) is lost; with each opened connection the chance of misidentification and sending data to the wrong drive is increased. Fiction. Or rather, heavily biased. Modern SATA hosts and PMs have no such issues. The key SATA term to ask for is FIS-based switching. The biggest difference between SATA and SAS, is the same one we previously had between ATA and SCSI: Vendors like to position SAS/SCSI as a premium brand, and therefore cripple SATA/ATA with lower spin-rates (7200rpm max, or 1rpm for WD Raptors, vs. 2rpm for high end SAS/SCSI). There may be other firmware algorithm differences as well, but RAID edition SATA/ATA drives have similar low-readahead and fast-seek programming as their SAS/SCSI counterparts. Simple spin-rate (RPM) is the most significant distinguishing factor in nearly all scenarios. SAS/SCSI may also still win when connecting a ridiculously large number of drives to a single port. Cheers - 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: SAS v SATA interface performance
Oh, more fiction: Because SATA uses point-to-point connectivity, the scaling available with SAS controllers is not possible with SATA controllers. SATA drives must be connected on a one-to-one basis with the SATA connectors on the controller – i.e, a fourport SATA controller can connect up to four drives, an eight-port SATA controller can connect up to eight drives, etc. This means that the number of drives needed must be known prior to purchasing a SATA controller, or additional hardware costs will be incurred. Ignoring port multipliers (hubs) again there. A SATA hub can connect up to 31 drives to a single SATA port, or up to 248 drives per 8-port PCI(X/e) controller card. I don't know if anyone currently sells a 31-port multiplier, though. Cheers - 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 0/3] OF-platform PATA driver
On Sun, Dec 02, 2007 at 02:58:10AM +0300, Anton Vorontsov wrote:
On Sat, Dec 01, 2007 at 05:54:49PM -0500, Jeff Garzik wrote:
while (1) {
send_patches();
if (ack_collected(PaulM) ack_collected(PowerPC_people))
break;
sleep(wait_for_comments_timeout); -- currently here.
I still haven't seen you address the compatible comments (that
pata-platform is suboptimal). Or did I miss some respin of the patches?
-Olof
-
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 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
+static struct of_device_id pata_of_platform_match[] = {
+ { .compatible = pata-platform, },
+};
On top of previous comment about the compatible string being
inappropriate:
You should add a MODULE_DEVICE_TABLE() entry for this. Dave Woodhouse
pointed out it's needed for autoloading modules (i.e. by the fedora
installer, etc).
-Olof
-
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
