* [PATCH 2/4] pata: imx: set controller PIO mode with .set_piomode callback
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
In-Reply-To: <20161109005638.17691-1-vz@mleia.com>
Convert .set_mode callback function to more specific .set_piomode,
the driver does not have support of DMA modes, thus a simpler version
of the callback is preferred.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/ata/pata_imx.c | 27 ++++++++-------------------
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index 203e309..00df18b 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -38,28 +38,17 @@ struct pata_imx_priv {
u32 ata_ctl;
};
-static int pata_imx_set_mode(struct ata_link *link, struct ata_device **unused)
+static void pata_imx_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
- struct ata_device *dev;
- struct ata_port *ap = link->ap;
struct pata_imx_priv *priv = ap->host->private_data;
u32 val;
- ata_for_each_dev(dev, link, ENABLED) {
- dev->pio_mode = dev->xfer_mode = XFER_PIO_0;
- dev->xfer_shift = ATA_SHIFT_PIO;
- dev->flags |= ATA_DFLAG_PIO;
-
- val = __raw_readl(priv->host_regs + PATA_IMX_ATA_CONTROL);
- if (ata_pio_need_iordy(dev))
- val |= PATA_IMX_ATA_CTRL_IORDY_EN;
- else
- val &= ~PATA_IMX_ATA_CTRL_IORDY_EN;
- __raw_writel(val, priv->host_regs + PATA_IMX_ATA_CONTROL);
-
- ata_dev_info(dev, "configured for PIO\n");
- }
- return 0;
+ val = __raw_readl(priv->host_regs + PATA_IMX_ATA_CONTROL);
+ if (ata_pio_need_iordy(adev))
+ val |= PATA_IMX_ATA_CTRL_IORDY_EN;
+ else
+ val &= ~PATA_IMX_ATA_CTRL_IORDY_EN;
+ __raw_writel(val, priv->host_regs + PATA_IMX_ATA_CONTROL);
}
static struct scsi_host_template pata_imx_sht = {
@@ -70,7 +59,7 @@ static struct ata_port_operations pata_imx_port_ops = {
.inherits = &ata_sff_port_ops,
.sff_data_xfer = ata_sff_data_xfer_noirq,
.cable_detect = ata_cable_unknown,
- .set_mode = pata_imx_set_mode,
+ .set_piomode = pata_imx_set_piomode,
};
static void pata_imx_setup_port(struct ata_ioports *ioaddr)
--
2.10.2
^ permalink raw reply related
* [PATCH 3/4] pata: imx: add support of setting timings for PIO modes
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
In-Reply-To: <20161109005638.17691-1-vz@mleia.com>
The controller is capable to operate in up to PIO4 mode, however
before the change the driver relies on timing settings done by
a bootloader for PIO0 mode only. The change adds more flexibility
in PIO mode selection at runtime and makes the driver to work even if
bootloader does not preset ATA timings.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/ata/pata_imx.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index 00df18b..8f13c9f 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -11,7 +11,6 @@
*
* TODO:
* - dmaengine support
- * - check if timing stuff needed
*/
#include <linux/ata.h>
@@ -22,6 +21,16 @@
#define DRV_NAME "pata_imx"
+#define PATA_IMX_ATA_TIME_OFF 0x00
+#define PATA_IMX_ATA_TIME_ON 0x01
+#define PATA_IMX_ATA_TIME_1 0x02
+#define PATA_IMX_ATA_TIME_2W 0x03
+#define PATA_IMX_ATA_TIME_2R 0x04
+#define PATA_IMX_ATA_TIME_AX 0x05
+#define PATA_IMX_ATA_TIME_PIO_RDX 0x06
+#define PATA_IMX_ATA_TIME_4 0x07
+#define PATA_IMX_ATA_TIME_9 0x08
+
#define PATA_IMX_ATA_CONTROL 0x24
#define PATA_IMX_ATA_CTRL_FIFO_RST_B (1<<7)
#define PATA_IMX_ATA_CTRL_ATA_RST_B (1<<6)
@@ -31,6 +40,10 @@
#define PATA_IMX_DRIVE_DATA 0xA0
#define PATA_IMX_DRIVE_CONTROL 0xD8
+static u32 pio_t4[] = { 30, 20, 15, 10, 10 };
+static u32 pio_t9[] = { 20, 15, 10, 10, 10 };
+static u32 pio_tA[] = { 35, 35, 35, 35, 35 };
+
struct pata_imx_priv {
struct clk *clk;
/* timings/interrupt/control regs */
@@ -38,11 +51,43 @@ struct pata_imx_priv {
u32 ata_ctl;
};
+static void pata_imx_set_timing(struct ata_device *adev,
+ struct pata_imx_priv *priv)
+{
+ struct ata_timing timing;
+ unsigned long clkrate;
+ u32 T, mode;
+
+ clkrate = clk_get_rate(priv->clk);
+
+ if (adev->pio_mode < XFER_PIO_0 || adev->pio_mode > XFER_PIO_4 ||
+ !clkrate)
+ return;
+
+ T = 1000000000 / clkrate;
+ ata_timing_compute(adev, adev->pio_mode, &timing, T * 1000, 0);
+
+ mode = adev->pio_mode - XFER_PIO_0;
+
+ writeb(3, priv->host_regs + PATA_IMX_ATA_TIME_OFF);
+ writeb(3, priv->host_regs + PATA_IMX_ATA_TIME_ON);
+ writeb(timing.setup, priv->host_regs + PATA_IMX_ATA_TIME_1);
+ writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2W);
+ writeb(timing.act8b, priv->host_regs + PATA_IMX_ATA_TIME_2R);
+ writeb(1, priv->host_regs + PATA_IMX_ATA_TIME_PIO_RDX);
+
+ writeb(pio_t4[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_4);
+ writeb(pio_t9[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_9);
+ writeb(pio_tA[mode] / T + 1, priv->host_regs + PATA_IMX_ATA_TIME_AX);
+}
+
static void pata_imx_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
struct pata_imx_priv *priv = ap->host->private_data;
u32 val;
+ pata_imx_set_timing(adev, priv);
+
val = __raw_readl(priv->host_regs + PATA_IMX_ATA_CONTROL);
if (ata_pio_need_iordy(adev))
val |= PATA_IMX_ATA_CTRL_IORDY_EN;
--
2.10.2
^ permalink raw reply related
* [PATCH 1/4] pata: imx: sort headers out
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
In-Reply-To: <20161109005638.17691-1-vz@mleia.com>
Put headers in alphabetic order and remove redundant ones.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/ata/pata_imx.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/pata_imx.c b/drivers/ata/pata_imx.c
index 139d207..203e309 100644
--- a/drivers/ata/pata_imx.c
+++ b/drivers/ata/pata_imx.c
@@ -13,14 +13,12 @@
* - dmaengine support
* - check if timing stuff needed
*/
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/blkdev.h>
-#include <scsi/scsi_host.h>
+
#include <linux/ata.h>
+#include <linux/clk.h>
#include <linux/libata.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
-#include <linux/clk.h>
#define DRV_NAME "pata_imx"
--
2.10.2
^ permalink raw reply related
* [PATCH 0/4] pata: imx: set timings for PIO modes up to PIO4
From: Vladimir Zapolskiy @ 2016-11-09 0:56 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz; +Cc: linux-ide
The changeset adds support of PIO modes up to PIO4 by setting
necessary timings in the driver, before the change it is assumed
that the timings are always set by a bootloader once and thus
only one possible PIO mode has been supported (PIO0). With
this change the driver can be used on boards without ATA controller
configuration done by a bootloader.
The change is tested on a legacy i.MX31 board with an HDD connected
by a 40-pin flat cable.
Vladimir Zapolskiy (4):
pata: imx: sort headers out
pata: imx: set controller PIO mode with .set_piomode callback
pata: imx: add support of setting timings for PIO modes
pata: imx: support controller modes up to PIO4
drivers/ata/pata_imx.c | 82 +++++++++++++++++++++++++++++++++++---------------
1 file changed, 57 insertions(+), 25 deletions(-)
--
2.10.2
^ permalink raw reply
* Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
From: Christoph Hellwig @ 2016-11-04 14:50 UTC (permalink / raw)
To: Juerg Haefliger
Cc: linux-kernel, linux-mm, kernel-hardening, linux-x86_64, vpk,
Tejun Heo, linux-ide
In-Reply-To: <20161104144534.14790-2-juerg.haefliger@hpe.com>
The libata parts here really need to be split out and the proper list
and maintainer need to be Cc'ed.
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index 051b6158d1b7..58af734be25d 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -715,7 +715,7 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
>
> DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
>
> - if (PageHighMem(page)) {
> + if (PageHighMem(page) || xpfo_page_is_unmapped(page)) {
> unsigned long flags;
>
> /* FIXME: use a bounce buffer */
> @@ -860,7 +860,7 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
>
> DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
>
> - if (PageHighMem(page)) {
> + if (PageHighMem(page) || xpfo_page_is_unmapped(page)) {
> unsigned long flags;
>
> /* FIXME: use bounce buffer */
> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
This is just piling one nasty hack on top of another. libata should
just use the highmem case unconditionally, as it is the correct thing
to do for all cases.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-03 14:43 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <0852f6ee-0535-aebe-c326-fb33edb42a13@vulnscan.org>
Bram Matthys schreef op 2016-11-03 08:46:
> Shaun Tancheff wrote on 2-11-2016 18:50:
>> On Tue, Nov 1, 2016 at 5:37 AM, Bram Matthys <syzop@vulnscan.org
>> <mailto:syzop@vulnscan.org>> wrote:
>>
>> Hi,
>>
>> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only
>> getting ~240MB/s
>> write speed. On Windows it's 490MB/s (yes, without cache).
>> The read speed is the same on both Linux and Windows, though.
>> Both are
>> 512MB/s.
>>
>> Any ideas what this could be? It can't be a slow SATA link as
>> read speed
>> are fine. And since write performance is fine on Windows so I'm
>> kinda
>> stunned. Not sure how to proceed / debug this any further.
>>
>> I'm testing with dd if=/dev/zero of=/dev/sdX bs=1M count=65536
>> conv=fdatasync. Results are similar without the conv=fdatasync.
>> On Windows
>> I test with AS SSD.
>> Prior to testing I do a ATA security erase to make sure the SSD
>> isn't
>> clearing any cells during the benchmark. (Previously I used
>> blkdiscard but
>> then realized this would only 'mark' the cells as unused so it
>> might do
>> the actual erasing in the background)
>> I tested this both with a 4.4.0 and 4.8.4 Linux kernel. Another
>> machines
>> (different hardware) has the same results. All have a SATA III
>> interface.
>>
>>
>> May I suggest that dd is unlikely to give you an accurate
>> measurement of
>> throughput.
>> I would suggest using something like 'fio' instead.
>>
>> sudo fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1
>> --rw=write \
>> --bsrange=1M-1M --filename=/dev/sdb --runtime=1000 --name=fio
>>
>> I routinely see 500+MB/s with the 2TB SSD I have here ...
>
> Thanks Shaun for your suggestion. I tried this and unfortunately the
> results are not much better with fio:
>
> To summarize, on Linux (4.8.5):
> * fio sync:
> * READ: 478MB/s
> * WRITE: 118MB/s
> * fio libaio:
> * READ: 511MB/s
> * WRITE: 163MB/s
> * dd:
> * READ: 526MB/s
> * WRITE: 235MB/s
I just installed FreeBSD on the system for testing purposes and I'm
getting 444MB/s write speed. That's almost double of Linux.
root@fbsd:/dev # time dd if=/dev/zero of=/dev/ada1 bs=1M count=131072
conv=sync
131072+0 records in
131072+0 records out
137438953472 bytes transferred in 308.931389 secs (444885041 bytes/sec)
12.941u 27.742s 5:08.93 12.1% 29+169k 0+1048576io 0pf+0w
Sorry didn't have fio on the system, but in in any case the 444MB/s is
a minimum.
Read speed is 500MB/s by the way.
So this slow write performance issue seems Linux-specific.
Any (other) tips to get write speeds at the same level as FreeBSD or
Windows would be highly appreciated.
Regards,
Bram
>
> On Windows (7):
> * AS SSD http://imgur.com/ygCINXF :
> * READ: 512MB/s
> * WRITE: 493MB/s
> * ATTO SSD (32GB data 1M/2M/4M bsize) http://imgur.com/46cbogr :
> * READ: 560MB/s
> * WRITE: 533MB/s
> (And a quick ATTO block size test http://imgur.com/MhuLjno )
>
> Output of the fio and dd commands are below.
>
> # fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1 --rw=read
> --bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
> fio: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=sync, iodepth=32
> fio-2.2.10
> Starting 1 process
> Jobs: 1 (f=1): [R(1)] [100.0% done] [472.0MB/0KB/0KB /s] [472/0/0
> iops] [eta 00m:00s]
> fio: (groupid=0, jobs=1): err= 0: pid=14727: Thu Nov 3 07:40:58 2016
> read : io=467388MB, bw=478604KB/s, iops=467, runt=1000002msec
> clat (usec): min=1901, max=10352, avg=2136.75, stdev=147.57
> lat (usec): min=1901, max=10353, avg=2137.03, stdev=147.59
> clat percentiles (usec):
> | 1.00th=[ 2024], 5.00th=[ 2064], 10.00th=[ 2064], 20.00th=[
> 2096],
> | 30.00th=[ 2128], 40.00th=[ 2128], 50.00th=[ 2128], 60.00th=[
> 2128],
> | 70.00th=[ 2160], 80.00th=[ 2160], 90.00th=[ 2192], 95.00th=[
> 2192],
> | 99.00th=[ 2320], 99.50th=[ 2352], 99.90th=[ 3568], 99.95th=[
> 6624],
> | 99.99th=[ 7776]
> bw (KB /s): min=286147, max=495616, per=100.00%, avg=479047.45,
> stdev=11395.42
> lat (msec) : 2=0.23%, 4=99.68%, 10=0.09%, 20=0.01%
> cpu : usr=0.21%, sys=5.20%, ctx=467427, majf=0, minf=265
> IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
> >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> issued : total=r=467388/w=0/d=0, short=r=0/w=0/d=0,
> drop=r=0/w=0/d=0
> latency : target=0, window=0, percentile=100.00%, depth=32
>
> Run status group 0 (all jobs):
> READ: io=467388MB, aggrb=478604KB/s, minb=478604KB/s,
> maxb=478604KB/s, mint=1000002msec, maxt=1000002msec
>
> Disk stats (read/write):
> sda: ios=934688/0, merge=0/0, ticks=1594452/0, in_queue=1594292,
> util=95.27%
>
> # fio --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --rw=read
> --bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
> fio: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio,
> iodepth=32
> fio-2.2.10
> Starting 1 process
> Jobs: 1 (f=1): [R(1)] [100.0% done] [507.0MB/0KB/0KB /s] [507/0/0
> iops] [eta 00m:00s]
> fio: (groupid=0, jobs=1): err= 0: pid=14761: Thu Nov 3 07:58:01 2016
> read : io=499290MB, bw=511241KB/s, iops=499, runt=1000062msec
> slat (usec): min=29, max=606, avg=56.90, stdev=21.02
> clat (msec): min=5, max=148, avg=64.03, stdev= 1.71
> lat (msec): min=5, max=148, avg=64.09, stdev= 1.71
> clat percentiles (msec):
> | 1.00th=[ 63], 5.00th=[ 63], 10.00th=[ 63], 20.00th=[
> 64],
> | 30.00th=[ 64], 40.00th=[ 64], 50.00th=[ 64], 60.00th=[
> 64],
> | 70.00th=[ 66], 80.00th=[ 67], 90.00th=[ 67], 95.00th=[
> 67],
> | 99.00th=[ 67], 99.50th=[ 67], 99.90th=[ 76], 99.95th=[
> 78],
> | 99.99th=[ 123]
> bw (KB /s): min=406738, max=521197, per=100.00%, avg=511739.76,
> stdev=11240.18
> lat (msec) : 10=0.01%, 20=0.01%, 50=0.01%, 100=99.97%, 250=0.03%
> cpu : usr=0.60%, sys=3.67%, ctx=499374, majf=0, minf=538
> IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%,
> >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%,
> >=64=0.0%
> issued : total=r=499290/w=0/d=0, short=r=0/w=0/d=0,
> drop=r=0/w=0/d=0
> latency : target=0, window=0, percentile=100.00%, depth=32
>
> Run status group 0 (all jobs):
> READ: io=499290MB, aggrb=511241KB/s, minb=511241KB/s,
> maxb=511241KB/s, mint=1000062msec, maxt=1000062msec
>
> Disk stats (read/write):
> sda: ios=514818/0, merge=0/0, ticks=32910900/0, in_queue=32911656,
> util=100.00%
>
> # time fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1
> --rw=write --bsrange=1M-1M --runtime=1000 --name=fio
> --filename=/dev/sda
> fio: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=sync, iodepth=32
> fio-2.2.10
> Starting 1 process
> Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/101.0MB/0KB /s] [0/101/0
> iops] [eta 00m:00s]
> fio: (groupid=0, jobs=1): err= 0: pid=14207: Wed Nov 2 20:48:09 2016
> write: io=116047MB, bw=118831KB/s, iops=116, runt=1000006msec
> clat (msec): min=4, max=24, avg= 8.58, stdev= 2.26
> lat (msec): min=4, max=24, avg= 8.61, stdev= 2.26
> clat percentiles (usec):
> | 1.00th=[ 5024], 5.00th=[ 5152], 10.00th=[ 5280], 20.00th=[
> 5664],
> | 30.00th=[ 6944], 40.00th=[ 9152], 50.00th=[ 9280], 60.00th=[
> 9536],
> | 70.00th=[ 9792], 80.00th=[10048], 90.00th=[10560],
> 95.00th=[11328],
> | 99.00th=[14400], 99.50th=[17280], 99.90th=[19328],
> 99.95th=[20352],
> | 99.99th=[21120]
> bw (KB /s): min=91610, max=202752, per=100.00%, avg=119006.32,
> stdev=31198.56
> lat (msec) : 10=79.69%, 20=20.24%, 50=0.06%
> cpu : usr=0.43%, sys=0.73%, ctx=116061, majf=0, minf=11
> IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
> >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> issued : total=r=0/w=116047/d=0, short=r=0/w=0/d=0,
> drop=r=0/w=0/d=0
> latency : target=0, window=0, percentile=100.00%, depth=32
>
> Run status group 0 (all jobs):
> WRITE: io=116047MB, aggrb=118831KB/s, minb=118831KB/s,
> maxb=118831KB/s, mint=1000006msec, maxt=1000006msec
>
> Disk stats (read/write):
> sda: ios=0/116037, merge=0/0, ticks=0/985368, in_queue=985316,
> util=98.61%
>
> real 16m40.461s
> user 0m5.472s
> sys 0m8.992s
>
> # time fio --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1
> --rw=write --bsrange=1M-1M --runtime=1000 --name=fio
> --filename=/dev/sda
> fio: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio,
> iodepth=32
> fio-2.2.10
> Starting 1 process
> Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/141.0MB/0KB /s] [0/141/0
> iops] [eta 00m:00s]
> fio: (groupid=0, jobs=1): err= 0: pid=14469: Wed Nov 2 21:22:17 2016
> write: io=159168MB, bw=162952KB/s, iops=159, runt=1000219msec
> slat (usec): min=34, max=621, avg=109.71, stdev=23.32
> clat (msec): min=78, max=539, avg=200.98, stdev=86.51
> lat (msec): min=78, max=539, avg=201.09, stdev=86.51
> clat percentiles (msec):
> | 1.00th=[ 83], 5.00th=[ 86], 10.00th=[ 89], 20.00th=[
> 105],
> | 30.00th=[ 176], 40.00th=[ 188], 50.00th=[ 200], 60.00th=[
> 212],
> | 70.00th=[ 227], 80.00th=[ 237], 90.00th=[ 255], 95.00th=[
> 408],
> | 99.00th=[ 469], 99.50th=[ 482], 99.90th=[ 498], 99.95th=[
> 502],
> | 99.99th=[ 519]
> bw (KB /s): min=104160, max=389120, per=100.00%, avg=166894.31,
> stdev=63045.67
> lat (msec) : 100=19.30%, 250=69.43%, 500=11.20%, 750=0.08%
> cpu : usr=0.97%, sys=0.83%, ctx=5748, majf=0, minf=11
> IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%,
> >=64=0.0%
> submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
> >=64=0.0%
> complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%,
> >=64=0.0%
> issued : total=r=0/w=159168/d=0, short=r=0/w=0/d=0,
> drop=r=0/w=0/d=0
> latency : target=0, window=0, percentile=100.00%, depth=32
>
> Run status group 0 (all jobs):
> WRITE: io=159168MB, aggrb=162952KB/s, minb=162952KB/s,
> maxb=162952KB/s, mint=1000219msec, maxt=1000219msec
>
> Disk stats (read/write):
> sda: ios=0/159136, merge=0/0, ticks=0/31683824, in_queue=31685776,
> util=100.00%
>
> real 16m40.684s
> user 0m10.840s
> sys 0m9.996s
>
> # time dd if=/dev/zero of=/dev/sda bs=1M count=65536 conv=fdatasync
> 65536+0 records in
> 65536+0 records out
> 68719476736 bytes (69 GB, 64 GiB) copied, 292.338 s, 235 MB/s
>
> real 4m52.342s
> user 0m0.024s
> sys 0m38.048s
>
> # echo 3 >/proc/sys/vm/drop_caches
>
> # time dd if=/dev/sda of=/dev/null bs=1M count=65536
> 65536+0 records in
> 65536+0 records out
> 68719476736 bytes (69 GB, 64 GiB) copied, 130.537 s, 526 MB/s
>
> real 2m10.543s
> user 0m0.028s
> sys 0m28.604s
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-03 7:46 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <CAJVOszDeJSXgdMuA-f6=JDSL78SBSz+-uDNp2PX=VTjeNyz4Bg@mail.gmail.com>
Shaun Tancheff wrote on 2-11-2016 18:50:
> On Tue, Nov 1, 2016 at 5:37 AM, Bram Matthys <syzop@vulnscan.org
> <mailto:syzop@vulnscan.org>> wrote:
>
> Hi,
>
> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting ~240MB/s
> write speed. On Windows it's 490MB/s (yes, without cache).
> The read speed is the same on both Linux and Windows, though. Both are
> 512MB/s.
>
> Any ideas what this could be? It can't be a slow SATA link as read speed
> are fine. And since write performance is fine on Windows so I'm kinda
> stunned. Not sure how to proceed / debug this any further.
>
> I'm testing with dd if=/dev/zero of=/dev/sdX bs=1M count=65536
> conv=fdatasync. Results are similar without the conv=fdatasync. On Windows
> I test with AS SSD.
> Prior to testing I do a ATA security erase to make sure the SSD isn't
> clearing any cells during the benchmark. (Previously I used blkdiscard but
> then realized this would only 'mark' the cells as unused so it might do
> the actual erasing in the background)
> I tested this both with a 4.4.0 and 4.8.4 Linux kernel. Another machines
> (different hardware) has the same results. All have a SATA III interface.
>
>
> May I suggest that dd is unlikely to give you an accurate measurement of
> throughput.
> I would suggest using something like 'fio' instead.
>
> sudo fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1 --rw=write \
> --bsrange=1M-1M --filename=/dev/sdb --runtime=1000 --name=fio
>
> I routinely see 500+MB/s with the 2TB SSD I have here ...
Thanks Shaun for your suggestion. I tried this and unfortunately the results
are not much better with fio:
To summarize, on Linux (4.8.5):
* fio sync:
* READ: 478MB/s
* WRITE: 118MB/s
* fio libaio:
* READ: 511MB/s
* WRITE: 163MB/s
* dd:
* READ: 526MB/s
* WRITE: 235MB/s
On Windows (7):
* AS SSD http://imgur.com/ygCINXF :
* READ: 512MB/s
* WRITE: 493MB/s
* ATTO SSD (32GB data 1M/2M/4M bsize) http://imgur.com/46cbogr :
* READ: 560MB/s
* WRITE: 533MB/s
(And a quick ATTO block size test http://imgur.com/MhuLjno )
Output of the fio and dd commands are below.
# fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1 --rw=read
--bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
fio: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=sync, iodepth=32
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [472.0MB/0KB/0KB /s] [472/0/0 iops] [eta
00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=14727: Thu Nov 3 07:40:58 2016
read : io=467388MB, bw=478604KB/s, iops=467, runt=1000002msec
clat (usec): min=1901, max=10352, avg=2136.75, stdev=147.57
lat (usec): min=1901, max=10353, avg=2137.03, stdev=147.59
clat percentiles (usec):
| 1.00th=[ 2024], 5.00th=[ 2064], 10.00th=[ 2064], 20.00th=[ 2096],
| 30.00th=[ 2128], 40.00th=[ 2128], 50.00th=[ 2128], 60.00th=[ 2128],
| 70.00th=[ 2160], 80.00th=[ 2160], 90.00th=[ 2192], 95.00th=[ 2192],
| 99.00th=[ 2320], 99.50th=[ 2352], 99.90th=[ 3568], 99.95th=[ 6624],
| 99.99th=[ 7776]
bw (KB /s): min=286147, max=495616, per=100.00%, avg=479047.45,
stdev=11395.42
lat (msec) : 2=0.23%, 4=99.68%, 10=0.09%, 20=0.01%
cpu : usr=0.21%, sys=5.20%, ctx=467427, majf=0, minf=265
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=467388/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: io=467388MB, aggrb=478604KB/s, minb=478604KB/s, maxb=478604KB/s,
mint=1000002msec, maxt=1000002msec
Disk stats (read/write):
sda: ios=934688/0, merge=0/0, ticks=1594452/0, in_queue=1594292, util=95.27%
# fio --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --rw=read
--bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
fio: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [507.0MB/0KB/0KB /s] [507/0/0 iops] [eta
00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=14761: Thu Nov 3 07:58:01 2016
read : io=499290MB, bw=511241KB/s, iops=499, runt=1000062msec
slat (usec): min=29, max=606, avg=56.90, stdev=21.02
clat (msec): min=5, max=148, avg=64.03, stdev= 1.71
lat (msec): min=5, max=148, avg=64.09, stdev= 1.71
clat percentiles (msec):
| 1.00th=[ 63], 5.00th=[ 63], 10.00th=[ 63], 20.00th=[ 64],
| 30.00th=[ 64], 40.00th=[ 64], 50.00th=[ 64], 60.00th=[ 64],
| 70.00th=[ 66], 80.00th=[ 67], 90.00th=[ 67], 95.00th=[ 67],
| 99.00th=[ 67], 99.50th=[ 67], 99.90th=[ 76], 99.95th=[ 78],
| 99.99th=[ 123]
bw (KB /s): min=406738, max=521197, per=100.00%, avg=511739.76,
stdev=11240.18
lat (msec) : 10=0.01%, 20=0.01%, 50=0.01%, 100=99.97%, 250=0.03%
cpu : usr=0.60%, sys=3.67%, ctx=499374, majf=0, minf=538
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued : total=r=499290/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: io=499290MB, aggrb=511241KB/s, minb=511241KB/s, maxb=511241KB/s,
mint=1000062msec, maxt=1000062msec
Disk stats (read/write):
sda: ios=514818/0, merge=0/0, ticks=32910900/0, in_queue=32911656, util=100.00%
# time fio --ioengine=sync --direct=1 --iodepth=32 --numjobs=1 --rw=write
--bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
fio: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=sync, iodepth=32
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/101.0MB/0KB /s] [0/101/0 iops] [eta
00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=14207: Wed Nov 2 20:48:09 2016
write: io=116047MB, bw=118831KB/s, iops=116, runt=1000006msec
clat (msec): min=4, max=24, avg= 8.58, stdev= 2.26
lat (msec): min=4, max=24, avg= 8.61, stdev= 2.26
clat percentiles (usec):
| 1.00th=[ 5024], 5.00th=[ 5152], 10.00th=[ 5280], 20.00th=[ 5664],
| 30.00th=[ 6944], 40.00th=[ 9152], 50.00th=[ 9280], 60.00th=[ 9536],
| 70.00th=[ 9792], 80.00th=[10048], 90.00th=[10560], 95.00th=[11328],
| 99.00th=[14400], 99.50th=[17280], 99.90th=[19328], 99.95th=[20352],
| 99.99th=[21120]
bw (KB /s): min=91610, max=202752, per=100.00%, avg=119006.32,
stdev=31198.56
lat (msec) : 10=79.69%, 20=20.24%, 50=0.06%
cpu : usr=0.43%, sys=0.73%, ctx=116061, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=116047/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: io=116047MB, aggrb=118831KB/s, minb=118831KB/s, maxb=118831KB/s,
mint=1000006msec, maxt=1000006msec
Disk stats (read/write):
sda: ios=0/116037, merge=0/0, ticks=0/985368, in_queue=985316, util=98.61%
real 16m40.461s
user 0m5.472s
sys 0m8.992s
# time fio --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --rw=write
--bsrange=1M-1M --runtime=1000 --name=fio --filename=/dev/sda
fio: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/141.0MB/0KB /s] [0/141/0 iops] [eta
00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=14469: Wed Nov 2 21:22:17 2016
write: io=159168MB, bw=162952KB/s, iops=159, runt=1000219msec
slat (usec): min=34, max=621, avg=109.71, stdev=23.32
clat (msec): min=78, max=539, avg=200.98, stdev=86.51
lat (msec): min=78, max=539, avg=201.09, stdev=86.51
clat percentiles (msec):
| 1.00th=[ 83], 5.00th=[ 86], 10.00th=[ 89], 20.00th=[ 105],
| 30.00th=[ 176], 40.00th=[ 188], 50.00th=[ 200], 60.00th=[ 212],
| 70.00th=[ 227], 80.00th=[ 237], 90.00th=[ 255], 95.00th=[ 408],
| 99.00th=[ 469], 99.50th=[ 482], 99.90th=[ 498], 99.95th=[ 502],
| 99.99th=[ 519]
bw (KB /s): min=104160, max=389120, per=100.00%, avg=166894.31,
stdev=63045.67
lat (msec) : 100=19.30%, 250=69.43%, 500=11.20%, 750=0.08%
cpu : usr=0.97%, sys=0.83%, ctx=5748, majf=0, minf=11
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=159168/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: io=159168MB, aggrb=162952KB/s, minb=162952KB/s, maxb=162952KB/s,
mint=1000219msec, maxt=1000219msec
Disk stats (read/write):
sda: ios=0/159136, merge=0/0, ticks=0/31683824, in_queue=31685776, util=100.00%
real 16m40.684s
user 0m10.840s
sys 0m9.996s
# time dd if=/dev/zero of=/dev/sda bs=1M count=65536 conv=fdatasync
65536+0 records in
65536+0 records out
68719476736 bytes (69 GB, 64 GiB) copied, 292.338 s, 235 MB/s
real 4m52.342s
user 0m0.024s
sys 0m38.048s
# echo 3 >/proc/sys/vm/drop_caches
# time dd if=/dev/sda of=/dev/null bs=1M count=65536
65536+0 records in
65536+0 records out
68719476736 bytes (69 GB, 64 GiB) copied, 130.537 s, 526 MB/s
real 2m10.543s
user 0m0.028s
sys 0m28.604s
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-02 15:07 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <adf65b5b8edfe0c1c99bc55a2827a68d@mail.vulnscan.org>
Bram Matthys wrote on 1-11-2016 11:37:
> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting ~240MB/s
> write speed. On Windows it's 490MB/s (yes, without cache).
> The read speed is the same on both Linux and Windows, though. Both are 512MB/s.
>
> Any ideas what this could be? It can't be a slow SATA link as read speed are
> fine. And since write performance is fine on Windows so I'm kinda stunned. Not
> sure how to proceed / debug this any further.
> [..]
I received the following reply from Samsung:
"Unfortunately, there is not much we can assist you with as Samsung does not
provide support for Linux operating systems."
So that isn't helping much :/
Regards,
Bram
^ permalink raw reply
* Re: [PATCH v2 34/37] docs: fix locations of several documents that got moved
From: Prarit Bhargava @ 2016-11-02 10:08 UTC (permalink / raw)
To: Pavel Machek, Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, Jonathan Corbet,
Rafael J. Wysocki, Len Brown, Jens Axboe, Alessandro Zummo,
Alexandre Belloni, Rob Herring, Mark Rutland, Jean Delvare,
Guenter Roeck, Karsten Keil, Mauro Carvalho Chehab,
Steffen Klassert, Greg Kroah-Hartman, Johannes Berg,
Jaroslav Kysela, Takashi Iwai, Paolo Bonzini <pbon>
In-Reply-To: <20161102093154.GC23350@amd>
On 11/02/2016 05:31 AM, Pavel Machek wrote:
> Hi!
>
>>> Dunno, but kernel-parameters.txt was already quite long... for a file
>>> that is referenced quite often. Adding admin-guide/ into the path does
>>> not really help.
>>
>> The big string name starts with Documentation/ :) There are some discussions
>> about changing it to doc/ (or docs/). Also, as you said, kernel-parameters
>> is already a big name. Perhaps we could use, instead,
>>> "kernel-parms".
>
> cmdline?
You would not believe the number of users I've dealt with that have confused
"cmdline/command line" (aka prompt) with "kernel parameter". I go back and edit
customer debug requests to make sure there's no use of cmdline in place of
kernel parameter.
For the love of every customer facing engineer out there, please stop using
cmdline ;).
P.
>
>> If we rename kernel-parameters.rst to kernel-parms.rst, plus the doc/ rename,
>> then the string size will actually reduce:
>>
>> - (see Documentation/kernel-parameters.txt), the minimum possible
>> + (see doc/admin-guide/kernel-parms.rst), the minimum possible
>>
>>> Maybe admin-guide should go directly into Documentation/ , as that's
>>> what our users are interested in?
>>
>> There are several problems if we keep them at Documentation/ dir:
>>
>> - We'll end by mixing documents already converted to ReST with documents
>> not converted yet;
>>
>> - A rename is needed anyway, as Sphinx only accepts ReST files that end
>> with the extension(s) defined at Documentation/conf.py (currently,
>> .rst);
>>
>> - A partial documentation build is made by sub-directory. If we put
>> files under /Documentation, there's no way to build just one
>> book.
>
> Well, documentation is primarily for users. I'm sure tools can adapt...
>
>>> Plus, I'm not sure how many developers will figure out that process/
>>> is what describes kernel patch submission process. We have processes
>>> in the kernel, after all...
>>
>> Do you have a better idea?
>
> development/ ?
>
> Best regards,
> Pavel
>
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 34/37] docs: fix locations of several documents that got moved
From: Pavel Machek @ 2016-11-02 9:31 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Nicolas Pitre, Linus Walleij, Jaroslav Kysela, Chris Metcalf,
Peter Loeffler, Finn Thain, Yaowei Bai, Jakub Wilk, linux-acpi,
Geert Uytterhoeven, Guenter Roeck, Petr Mladek, Jean Delvare,
linux-pm, Alexander Viro, Andy Lutomirski, Thomas Gleixner,
Karsten Keil, Jiri Kosina, seokhoon.yoon, Li Zefan, Ryan Swan,
Joe Perches, Andrew Morton, Mark
In-Reply-To: <20161019115918.1162d16e@vento.lan>
[-- Attachment #1.1: Type: text/plain, Size: 1794 bytes --]
Hi!
> > Dunno, but kernel-parameters.txt was already quite long... for a file
> > that is referenced quite often. Adding admin-guide/ into the path does
> > not really help.
>
> The big string name starts with Documentation/ :) There are some discussions
> about changing it to doc/ (or docs/). Also, as you said, kernel-parameters
> is already a big name. Perhaps we could use, instead,
> > "kernel-parms".
cmdline?
> If we rename kernel-parameters.rst to kernel-parms.rst, plus the doc/ rename,
> then the string size will actually reduce:
>
> - (see Documentation/kernel-parameters.txt), the minimum possible
> + (see doc/admin-guide/kernel-parms.rst), the minimum possible
>
> > Maybe admin-guide should go directly into Documentation/ , as that's
> > what our users are interested in?
>
> There are several problems if we keep them at Documentation/ dir:
>
> - We'll end by mixing documents already converted to ReST with documents
> not converted yet;
>
> - A rename is needed anyway, as Sphinx only accepts ReST files that end
> with the extension(s) defined at Documentation/conf.py (currently,
> .rst);
>
> - A partial documentation build is made by sub-directory. If we put
> files under /Documentation, there's no way to build just one
> book.
Well, documentation is primarily for users. I'm sure tools can adapt...
> > Plus, I'm not sure how many developers will figure out that process/
> > is what describes kernel patch submission process. We have processes
> > in the kernel, after all...
>
> Do you have a better idea?
development/ ?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] libata-scsi: Fixup ata_gen_passthru_sense()
From: Tejun Heo @ 2016-11-01 17:33 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: Charles Machalow, linux-ide, Hannes Reinecke
In-Reply-To: <1477944418-110380-1-git-send-email-hare@suse.de>
On Mon, Oct 31, 2016 at 09:06:58PM +0100, Hannes Reinecke wrote:
> There's a typo in ata_gen_passthru_sense(), where the first byte
> would be overwritten incorrectly later on.
>
> Reported-by: Charles Machalow <csm10495@gmail.com>
> Signed-off-by: Hannes Reinecke <hare@suse.com>
Applied to libata/for-4.9-fixes with stable cc'd.
Thanks.
--
tejun
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-01 13:55 UTC (permalink / raw)
To: linux-ide
Hi Daniel,
Daniel Fraga schreef op 2016-11-01 14:03:
> On Tue, 01 Nov 2016 11:37:42 +0100
> Bram Matthys <syzop@vulnscan.org> wrote:
>
>> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting
>> ~240MB/s write speed. On Windows it's 490MB/s (yes, without cache).
>> The read speed is the same on both Linux and Windows, though. Both
>> are
>> 512MB/s.
>
> Just curious: are you using the "deadline" scheduler? What file
> system? Ext4?
Yes, the deadline scheduler.
On Linux I'm writing directly to /dev/sda, no file system.
Regards,
Bram
^ permalink raw reply
* Re: Write performance 50% compared to Windows
From: Dâniel Fraga @ 2016-11-01 13:03 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <adf65b5b8edfe0c1c99bc55a2827a68d@mail.vulnscan.org>
On Tue, 01 Nov 2016 11:37:42 +0100
Bram Matthys <syzop@vulnscan.org> wrote:
> I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting
> ~240MB/s write speed. On Windows it's 490MB/s (yes, without cache).
> The read speed is the same on both Linux and Windows, though. Both are
> 512MB/s.
Just curious: are you using the "deadline" scheduler? What file
system? Ext4?
--
https://exchangewar.info
^ permalink raw reply
* Write performance 50% compared to Windows
From: Bram Matthys @ 2016-11-01 10:37 UTC (permalink / raw)
To: linux-ide
Hi,
I have a Samsung SSD 850 EVO 4TB and under Linux I'm only getting
~240MB/s write speed. On Windows it's 490MB/s (yes, without cache).
The read speed is the same on both Linux and Windows, though. Both are
512MB/s.
Any ideas what this could be? It can't be a slow SATA link as read
speed are fine. And since write performance is fine on Windows so I'm
kinda stunned. Not sure how to proceed / debug this any further.
I'm testing with dd if=/dev/zero of=/dev/sdX bs=1M count=65536
conv=fdatasync. Results are similar without the conv=fdatasync. On
Windows I test with AS SSD.
Prior to testing I do a ATA security erase to make sure the SSD isn't
clearing any cells during the benchmark. (Previously I used blkdiscard
but then realized this would only 'mark' the cells as unused so it might
do the actual erasing in the background)
I tested this both with a 4.4.0 and 4.8.4 Linux kernel. Another
machines (different hardware) has the same results. All have a SATA III
interface.
Dmesg:
[ 4.741663] ata2.00: ATA-9: Samsung SSD 850 EVO 4TB, EMT02B6Q, max
UDMA/133
[ 4.752974] ata1.00: ATA-9: Samsung SSD 850 EVO 4TB, EMT02B6Q, max
UDMA/133
# cat /sys/block/sda/device/queue_depth
31
If you need anything else let me know. Any help is welcomed.
Regards,
Bram
^ permalink raw reply
* Re: sata_sil24: swiotlb buffer is full ?
From: Andrew Ryder @ 2016-10-31 20:14 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Tejun Heo; +Cc: linux-ide, linux-kernel
In-Reply-To: <20161031190918.GE15811@char.us.oracle.com>
On 10/31/2016 03:09 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 31, 2016 at 10:18:25AM -0600, Tejun Heo wrote:
>> Hello,
>>
>> On Sat, Oct 29, 2016 at 11:40:29PM -0400, Andrew Ryder wrote:
>>> I have some disks attached to a "Silicon Image, Inc. SiI 3124 PCI-X Serial
>>> ATA Controller" and it repeatedly locks up the system with the message
>>> whenever there is heavy disk i/o. The system the controller is attached to
>>> is a via EPIA-M910 board.
>>>
>>> sata_sil24: 0000:06:03.0: swiotlb buffer is full: 65536 bytes)
>>> DMA: Out of SW-IOMMU space for 65536 bytes at device .."
>>> sata_sil24 0000:06:03.0: swiotlb buffer is full (sz: 65536 bytes .."
>>>
>>> For the past week I have been running with two additional boot parameters
>>> (iommu=allowdac swiotlb=131072) which seem to have solved the issue, but I
>>> was curious if this is a driver bug or not?
>
> Usually it means that the device (sta_sil24) can only handle certain
> DMA addresses and hence needs the assistance of the bounce buffers (swiotlb).
>
> Increasing the number of them is the right way to make it work.
>
> I would call this hardware limitation - if you provide the lspci -n -s 06:03.0
> one can look in the driver and see where it sets the DMA mask.
Here is the output of the lspci commad as well as one additional in case
you need it. I've had the issue on both 3.19.8 and 4.0.4 kernels if its
relevant.
Here is a link to the controller card also if needed?
http://www.addonics.com/products/adsa4r5.php
~ # lspci -n -s 06:03.0
06:03.0 0104: 1095:3124 (rev 02)
~ # lspci -vvvvns 06:03.0
06:03.0 0104: 1095:3124 (rev 02)
Subsystem: 1095:7124
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop-
ParErr- Stepping+ SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at feb77c00 (64-bit, non-prefetchable) [size=128]
Region 2: Memory at feb78000 (64-bit, non-prefetchable) [size=32K]
Region 4: I/O ports at ec00 [size=16]
Expansion ROM at feb80000 [disabled] [size=512K]
Capabilities: [64] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [40] PCI-X non-bridge device
Command: DPERE- ERO+ RBC=512 OST=12
Status: Dev=ff:1f.0 64bit+ 133MHz+ SCD- USC- DC=simple
DMMRBC=2048 DMOST=12 DMCRS=128 RSCEM- 266MHz- 533MHz-
Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Kernel driver in use: sata_sil24
Kernel modules: sata_sil24
>
>>
>> (cc'ing swiotbl maintainer, hi!)
>>
>> That looks like iotlb area running out. I don't think there's much to
>> be done from driver side and we've traditionally been pretty bad at
>> handling iotlb errors. Konrad, do you have any ideas?
>>
>> Thanks.
>>
>> --
>> tejun
>
^ permalink raw reply
* Re: Possible Bug In ATA/SCSI Fixed Sense
From: Hannes Reinecke @ 2016-10-31 20:09 UTC (permalink / raw)
To: Tejun Heo, Charles Machalow; +Cc: linux-ide
In-Reply-To: <20161031155840.GA24605@mtj.duckdns.org>
On 10/31/2016 04:58 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Oct 28, 2016 at 11:34:22AM -0700, Charles Machalow wrote:
>> As of Linux commit 14970f204b1993af7459d5bd34aaff38dfee6670, In
>> drivers/ata/libata-scsi.c in ata_gen_passthru_sense() line 1087,
>> desc[0] is set to tf->feature. This makes sense to me however 4 lines
>> below the same item in the array is set to 0.
>>
>> One of these lines must be unintended as no matter what the field will
>> always be 0 though for a couple lines it is set to tf-feature.
>>
>> I think that line 1091 is at fault because if I send down a nop
>> command, feature (error in this case) should be set to 4 in the
>> returned current task file.
>
> This looks to be from 11093cb1ef56 ("libata-scsi: generate correct ATA
> pass-through sense"). Hannes?
>
Indeed, that's an error.
I wanted to set byte 7 to zero, indicating there is no additional sense
data to be had.
Patch has been sent.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
^ permalink raw reply
* [PATCH] libata-scsi: Fixup ata_gen_passthru_sense()
From: Hannes Reinecke @ 2016-10-31 20:06 UTC (permalink / raw)
To: Tejun Heo; +Cc: Charles Machalow, linux-ide, Hannes Reinecke, Hannes Reinecke
There's a typo in ata_gen_passthru_sense(), where the first byte
would be overwritten incorrectly later on.
Reported-by: Charles Machalow <csm10495@gmail.com>
Signed-off-by: Hannes Reinecke <hare@suse.com>
---
drivers/ata/libata-scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 9cceb4a..c4eb4ae 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1088,7 +1088,7 @@ static void ata_gen_passthru_sense(struct ata_queued_cmd *qc)
desc[1] = tf->command; /* status */
desc[2] = tf->device;
desc[3] = tf->nsect;
- desc[0] = 0;
+ desc[7] = 0;
if (tf->flags & ATA_TFLAG_LBA48) {
desc[8] |= 0x80;
if (tf->hob_nsect)
--
2.6.6
^ permalink raw reply related
* Re: sata_sil24: swiotlb buffer is full ?
From: Konrad Rzeszutek Wilk @ 2016-10-31 19:09 UTC (permalink / raw)
To: Tejun Heo; +Cc: Andrew Ryder, linux-ide, linux-kernel
In-Reply-To: <20161031161825.GA26364@mtj.duckdns.org>
On Mon, Oct 31, 2016 at 10:18:25AM -0600, Tejun Heo wrote:
> Hello,
>
> On Sat, Oct 29, 2016 at 11:40:29PM -0400, Andrew Ryder wrote:
> > I have some disks attached to a "Silicon Image, Inc. SiI 3124 PCI-X Serial
> > ATA Controller" and it repeatedly locks up the system with the message
> > whenever there is heavy disk i/o. The system the controller is attached to
> > is a via EPIA-M910 board.
> >
> > sata_sil24: 0000:06:03.0: swiotlb buffer is full: 65536 bytes)
> > DMA: Out of SW-IOMMU space for 65536 bytes at device .."
> > sata_sil24 0000:06:03.0: swiotlb buffer is full (sz: 65536 bytes .."
> >
> > For the past week I have been running with two additional boot parameters
> > (iommu=allowdac swiotlb=131072) which seem to have solved the issue, but I
> > was curious if this is a driver bug or not?
Usually it means that the device (sta_sil24) can only handle certain
DMA addresses and hence needs the assistance of the bounce buffers (swiotlb).
Increasing the number of them is the right way to make it work.
I would call this hardware limitation - if you provide the lspci -n -s 06:03.0
one can look in the driver and see where it sets the DMA mask.
>
> (cc'ing swiotbl maintainer, hi!)
>
> That looks like iotlb area running out. I don't think there's much to
> be done from driver side and we've traditionally been pretty bad at
> handling iotlb errors. Konrad, do you have any ideas?
>
> Thanks.
>
> --
> tejun
^ permalink raw reply
* Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-10-31 18:24 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Arnd Bergmann, linux-arm-kernel, Dmitry Eremin-Solenikov,
linux-kernel, linux-ide, Olof Johansson, Kevin Hilman,
Nori, Sekhar
In-Reply-To: <2291876.8LAt3RcuXX@amdc3058>
On Monday, October 31, 2016 07:14:13 PM Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > Hi,
> > >
> > > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> > > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > >
> > > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > > > > (no IDE host drivers are selected in this config so there is no
> > > > > > > valid reason to enable IDE subsystem itself).
> > > > > > >
> > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > > >
> > > > > > I think the series makes a lot of sense. I have checked your assertions
> > > > > > in the changelogs and found no flaws in your logic, so I think we should
> > > > > > take them all through arm-soc unless there are other concerns.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Should I resend everything or just patches that were not reposted yet
> > > > > (the ones that were marked as RFT initially and got no feedback)?
> > > >
> > > > I'd be fine with just getting a pull request with all the patches that
> > > > had no negative feedback and that were not already applied (if any).
> > >
> > > Here it is (sorry for taking so long).
> >
> > I've just been digging in the dmesg logs from when I was using the
> > Assabet+Neponset as my firewall, and it was having to use the IDE
> > ide-cs driver rather than the pata pcmcia driver.
> >
> > I don't recall whether the pata pcmcia driver was a problem or not,
> > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> > think PATA tries to use the "highest" possible access size by
> > default...
>
> It doesn't actually - it defaults to 16-bits for PIO data access and
> you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
> (pata_pcmcia doesn't set it so it should be okay). Also taskfile
> registers are accessed using 8-bits access by default transport
> functions (which are used by pata_pcmcia).
Please also note that:
- assebet_defconfig currently doesn't even enable ide-cs
(CONFIG_BLK_DEV_IDECS) in the mainline kernel
- neponset_defconfig doesn't even enable IDE (CONFIG_IDE)
in the mainline kernel
so there is no risk of breaking anything.. :-)
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-10-31 18:14 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Arnd Bergmann, Dmitry Eremin-Solenikov, Kevin Hilman,
Nori, Sekhar, linux-kernel, linux-ide, Olof Johansson,
linux-arm-kernel
In-Reply-To: <20161031154622.GB1041@n2100.armlinux.org.uk>
Hi,
On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > > > (no IDE host drivers are selected in this config so there is no
> > > > > > valid reason to enable IDE subsystem itself).
> > > > > >
> > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > >
> > > > > I think the series makes a lot of sense. I have checked your assertions
> > > > > in the changelogs and found no flaws in your logic, so I think we should
> > > > > take them all through arm-soc unless there are other concerns.
> > > >
> > > > Thank you.
> > > >
> > > > Should I resend everything or just patches that were not reposted yet
> > > > (the ones that were marked as RFT initially and got no feedback)?
> > >
> > > I'd be fine with just getting a pull request with all the patches that
> > > had no negative feedback and that were not already applied (if any).
> >
> > Here it is (sorry for taking so long).
>
> I've just been digging in the dmesg logs from when I was using the
> Assabet+Neponset as my firewall, and it was having to use the IDE
> ide-cs driver rather than the pata pcmcia driver.
>
> I don't recall whether the pata pcmcia driver was a problem or not,
> as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> think PATA tries to use the "highest" possible access size by
> default...
It doesn't actually - it defaults to 16-bits for PIO data access and
you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
(pata_pcmcia doesn't set it so it should be okay). Also taskfile
registers are accessed using 8-bits access by default transport
functions (which are used by pata_pcmcia).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: sata_sil24: swiotlb buffer is full ?
From: Tejun Heo @ 2016-10-31 16:18 UTC (permalink / raw)
To: Andrew Ryder; +Cc: linux-ide, Konrad Rzeszutek Wilk, linux-kernel
In-Reply-To: <8b6da1a2-ca9c-e15a-10a8-f3cda092698c@shaw.ca>
Hello,
On Sat, Oct 29, 2016 at 11:40:29PM -0400, Andrew Ryder wrote:
> I have some disks attached to a "Silicon Image, Inc. SiI 3124 PCI-X Serial
> ATA Controller" and it repeatedly locks up the system with the message
> whenever there is heavy disk i/o. The system the controller is attached to
> is a via EPIA-M910 board.
>
> sata_sil24: 0000:06:03.0: swiotlb buffer is full: 65536 bytes)
> DMA: Out of SW-IOMMU space for 65536 bytes at device .."
> sata_sil24 0000:06:03.0: swiotlb buffer is full (sz: 65536 bytes .."
>
> For the past week I have been running with two additional boot parameters
> (iommu=allowdac swiotlb=131072) which seem to have solved the issue, but I
> was curious if this is a driver bug or not?
(cc'ing swiotbl maintainer, hi!)
That looks like iotlb area running out. I don't think there's much to
be done from driver side and we've traditionally been pretty bad at
handling iotlb errors. Konrad, do you have any ideas?
Thanks.
--
tejun
^ permalink raw reply
* Re: Possible Bug In ATA/SCSI Fixed Sense
From: Tejun Heo @ 2016-10-31 15:58 UTC (permalink / raw)
To: Charles Machalow; +Cc: linux-ide, Hannes Reinecke
In-Reply-To: <CANSCoS8aVbdcb7ZCxcW57FrqKr_k+OuHt0ZFzPLNQRQMZj_Gww@mail.gmail.com>
Hello,
On Fri, Oct 28, 2016 at 11:34:22AM -0700, Charles Machalow wrote:
> As of Linux commit 14970f204b1993af7459d5bd34aaff38dfee6670, In
> drivers/ata/libata-scsi.c in ata_gen_passthru_sense() line 1087,
> desc[0] is set to tf->feature. This makes sense to me however 4 lines
> below the same item in the array is set to 0.
>
> One of these lines must be unintended as no matter what the field will
> always be 0 though for a couple lines it is set to tf-feature.
>
> I think that line 1091 is at fault because if I send down a nop
> command, feature (error in this case) should be set to 4 in the
> returned current task file.
This looks to be from 11093cb1ef56 ("libata-scsi: generate correct ATA
pass-through sense"). Hannes?
Thanks.
--
tejun
^ permalink raw reply
* Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Russell King - ARM Linux @ 2016-10-31 15:46 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Arnd Bergmann, linux-arm-kernel, Dmitry Eremin-Solenikov,
linux-kernel, linux-ide, Olof Johansson, Kevin Hilman,
Nori, Sekhar
In-Reply-To: <1913139.FJW82OAuEF@amdc3058>
On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > >
> > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > > (no IDE host drivers are selected in this config so there is no
> > > > > valid reason to enable IDE subsystem itself).
> > > > >
> > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > >
> > > > I think the series makes a lot of sense. I have checked your assertions
> > > > in the changelogs and found no flaws in your logic, so I think we should
> > > > take them all through arm-soc unless there are other concerns.
> > >
> > > Thank you.
> > >
> > > Should I resend everything or just patches that were not reposted yet
> > > (the ones that were marked as RFT initially and got no feedback)?
> >
> > I'd be fine with just getting a pull request with all the patches that
> > had no negative feedback and that were not already applied (if any).
>
> Here it is (sorry for taking so long).
I've just been digging in the dmesg logs from when I was using the
Assabet+Neponset as my firewall, and it was having to use the IDE
ide-cs driver rather than the pata pcmcia driver.
I don't recall whether the pata pcmcia driver was a problem or not,
as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
think PATA tries to use the "highest" possible access size by
default...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* sata_sil24: swiotlb buffer is full ?
From: Andrew Ryder @ 2016-10-30 3:40 UTC (permalink / raw)
To: linux-ide
Hello,
I have some disks attached to a "Silicon Image, Inc. SiI 3124 PCI-X
Serial ATA Controller" and it repeatedly locks up the system with the
message whenever there is heavy disk i/o. The system the controller is
attached to is a via EPIA-M910 board.
sata_sil24: 0000:06:03.0: swiotlb buffer is full: 65536 bytes)
DMA: Out of SW-IOMMU space for 65536 bytes at device .."
sata_sil24 0000:06:03.0: swiotlb buffer is full (sz: 65536 bytes .."
For the past week I have been running with two additional boot
parameters (iommu=allowdac swiotlb=131072) which seem to have solved the
issue, but I was curious if this is a driver bug or not?
Thanks,
Andrew
^ permalink raw reply
* [Bug 185531] New: pata_hpt366 irq xx: nobody cared
From: bugzilla-daemon @ 2016-10-28 20:13 UTC (permalink / raw)
To: linux-ide
https://bugzilla.kernel.org/show_bug.cgi?id=185531
Bug ID: 185531
Summary: pata_hpt366 irq xx: nobody cared
Product: IO/Storage
Version: 2.5
Kernel Version: Linux 4.4.0-45-generic Ubuntu SMP x86_64
Hardware: Intel
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IDE
Assignee: io_ide@kernel-bugs.osdl.org
Reporter: ilario.gottardello@gmail.com
Regression: No
Some time after boot, a spurious interrupt make this driver downgrade
performance from udma to pio. This interrupt is assigned solely to this card,
as says /proc/interrupts:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7
19: 4147 0 0 188 195666 0
0 0 IO-APIC 19-fasteoi pata_hpt366, pata_hpt366
This is the relevant part from dmesg:
[ 3049.573902] irq 19: nobody cared (try booting with the "irqpoll" option)
[ 3049.573910] CPU: 4 PID: 0 Comm: swapper/4 Tainted: P OE
4.4.0-45-generic #66-Ubuntu
[ 3049.573912] Hardware name: System manufacturer System Product Name/P8H67-V,
BIOS 3707 07/12/2013
[ 3049.573915] 0000000000000086 d86ed4c7c37291ec ffff88012f303e60
ffffffff813f1fe3
[ 3049.573919] ffff8800c07a5a00 ffff8800c07a5ab4 ffff88012f303e88
ffffffff810dd7a3
[ 3049.573922] ffff8800c07a5a00 0000000000000000 0000000000000013
ffff88012f303ec0
[ 3049.573925] Call Trace:
[ 3049.573927] <IRQ> [<ffffffff813f1fe3>] dump_stack+0x63/0x90
[ 3049.573940] [<ffffffff810dd7a3>] __report_bad_irq+0x33/0xc0
[ 3049.573943] [<ffffffff810ddb37>] note_interrupt+0x247/0x290
[ 3049.573946] [<ffffffff810dadc7>] handle_irq_event_percpu+0x167/0x1d0
[ 3049.573949] [<ffffffff810dae6e>] handle_irq_event+0x3e/0x60
[ 3049.573952] [<ffffffff810de0a6>] handle_fasteoi_irq+0x96/0x150
[ 3049.573956] [<ffffffff810310fa>] handle_irq+0x1a/0x30
[ 3049.573962] [<ffffffff8183429b>] do_IRQ+0x4b/0xd0
[ 3049.573965] [<ffffffff81832382>] common_interrupt+0x82/0x82
[ 3049.573966] <EOI> [<ffffffff816c4dce>] ? cpuidle_enter_state+0x10e/0x2b0
[ 3049.573975] [<ffffffff816c4fa7>] cpuidle_enter+0x17/0x20
[ 3049.573979] [<ffffffff810c4112>] call_cpuidle+0x32/0x60
[ 3049.573982] [<ffffffff816c4f83>] ? cpuidle_select+0x13/0x20
[ 3049.573986] [<ffffffff810c43d0>] cpu_startup_entry+0x290/0x350
[ 3049.573989] [<ffffffff810516e4>] start_secondary+0x154/0x190
[ 3049.573992] handlers:
[ 3049.573995] [<ffffffff815e81e0>] ata_bmdma_interrupt
[ 3049.573997] [<ffffffff815e81e0>] ata_bmdma_interrupt
[ 3049.573999] Disabling IRQ #19
Already changed cables and moved the card in another slot, the issue still
appears.
I'm willing to help debug the issue. Thanks in advance.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox