* 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
* Possible Bug In ATA/SCSI Fixed Sense
From: Charles Machalow @ 2016-10-28 18:34 UTC (permalink / raw)
To: tj; +Cc: linux-ide
Hi all,
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.
Thanks!
- Charlie Scott Machalow
^ permalink raw reply
* Re: [RFC PATCH] ata: piix: wait for end of asynchronous probing before
From: Tejun Heo @ 2016-10-27 18:59 UTC (permalink / raw)
To: Rob Herring
Cc: Corentin Labbe, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org, Greg Kroah-Hartman
In-Reply-To: <CAL_Jsq+HPd2Ftm7cDD4rpT6jx=EgS9nX+_WiwRcxhpPbi=85xQ@mail.gmail.com>
Hello, Rob.
On Thu, Oct 27, 2016 at 01:55:19PM -0500, Rob Herring wrote:
> Seems like this is mixing async drv probe and async scsi scan and the
> problem is in the latter? I don't think async drv probe should have
> any problems. If a driver probe starts some async operation, then it
> seems to me that it is its responsibility to wait for completion in
> remove().
I'm not sure about that. The async operation synchronization isn't
per-driver or module. Both during boot and module operations, they're
synchronized globally, which makes sense given its purpose and that's
also why we don't see these brekages without this debug option. It
doesn't make sense to me to add a whole new set of behaviors just for
a debug option.
Thanks.
--
tejun
^ permalink raw reply
* Re: [RFC PATCH] ata: piix: wait for end of asynchronous probing before
From: Rob Herring @ 2016-10-27 18:55 UTC (permalink / raw)
To: Tejun Heo
Cc: Corentin Labbe, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org, Greg Kroah-Hartman
In-Reply-To: <20161019172848.GD18532@htj.duckdns.org>
On Wed, Oct 19, 2016 at 12:28 PM, Tejun Heo <tj@kernel.org> wrote:
> (cc'ing Greg and Rob)
>
> Hello,
>
> On Mon, Oct 17, 2016 at 06:45:04PM +0200, Corentin Labbe wrote:
>> Enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE under qemu give me a WARN() trace.
>> Waiting for the end of the ATA RESET seems to clean the issue.
>> But I am not sure if my solution and the way to solve it are correct.
>>
>> Regards
>>
>> ---8<---
>> From b2d097130a9d67529075f6e3c3d9552ac5415d18 Mon Sep 17 00:00:00 2001
>> From: Corentin Labbe <clabbe.montjoie@gmail.com>
>> Date: Mon, 17 Oct 2016 17:50:02 +0200
>> Subject: [RFC PATCH] ata: piix: wait for end of asynchronous probing before
>> removing
>>
>> Under qemu I got the following trace with CONFIG_DEBUG_TEST_DRIVER_REMOVE
>> [ 1.092021] ata_piix 0000:00:01.1: version 2.13
>> [ 1.093277] scsi host0: ata_piix
>> [ 1.093720] scsi host1: ata_piix
>> [ 1.094152] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc080 irq 14
>> [ 1.094902] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc088 irq 15
>> [ 1.252998] ------------[ cut here ]------------
>> [ 1.253799] WARNING: CPU: 0 PID: 1 at drivers/ata/libata-core.c:6482 ata_host_detach+0x148/0x150
>
> I don't think it's correct to try to remove the driver while async
> probing is in progress and we shouldn't work around it from individual
> drivers. I think we already have enough async barriers to prevents
> this under normal operation - there's full synchronization during boot
> before control gets passed to userland and module unloading does full
> async flushing too. What we should do, probably, is to make the debug
> code do full async flush before test unloading the driver.
Seems like this is mixing async drv probe and async scsi scan and the
problem is in the latter? I don't think async drv probe should have
any problems. If a driver probe starts some async operation, then it
seems to me that it is its responsibility to wait for completion in
remove().
Rob
^ permalink raw reply
* [Bug 184221] New: 1-877-424-6647 | Mozilla Firefox customer service support phone number | Mozilla Firefox e technical support phone number, Mozilla Firefox support phone number
From: bugzilla-daemon @ 2016-10-27 18:53 UTC (permalink / raw)
To: linux-ide
https://bugzilla.kernel.org/show_bug.cgi?id=184221
Bug ID: 184221
Summary: 1-877-424-6647 | Mozilla Firefox customer service
support phone number | Mozilla Firefox e technical
support phone number, Mozilla Firefox support phone
number
Product: IO/Storage
Version: 2.5
Kernel Version: 1-877-424-6647 | Mozilla Firefox customer service
support phone number | Mozilla Firefox e technical
support phone number, Mozilla Firefox support phone
number
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IDE
Assignee: io_ide@kernel-bugs.osdl.org
Reporter: arlett@t3t97d1d.com
Regression: No
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
https://answers.avira.com/en/question/contact-mozilla-firefox-18774246647-firefox-tech-support-p-62701
https://plus.google.com/100457091534453063311/posts/VAJ3ZNXzNxz
http://woto.com/tkvn4o
Contact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number
++ Thunderbird Email phone number Contact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone number Contact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone number Contact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone number Contact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone numberContact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone numberContact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone numberContact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone numberContact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone numberContact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone numberContact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone numberContact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone numberContact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone number
https://forum.bitdefender.com/index.php?/topic/73380-contact-1800-790-9186-mozilla-firefox-support-phone-number-mozilla/
https://www.jotform.com/answers/969665-Contact-1800
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* 2706805393 linux-ide
From: lucia.germino @ 2016-10-27 2:55 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: INFO_29777_linux-ide.zip --]
[-- Type: application/zip, Size: 5365 bytes --]
^ permalink raw reply
* Re: [RFC] libata-scsi: introducing SANITIZE translation
From: Mark Lord @ 2016-10-26 22:44 UTC (permalink / raw)
To: Tom Yan, James Bottomley
Cc: Tejun Heo, martin.petersen, dgilbert, linux-ide, linux-scsi
In-Reply-To: <CAGnHSEms1rwy7-+URRMrdggpk=_7YVijHwf1h93iBKW7zLxh8g@mail.gmail.com>
On 16-07-11 02:35 AM, Tom Yan wrote:
> I don't suppose there would be any problem doing it in userspace /
> with ATA PASS-THROUGH anyway.
..
>>> On 8 July 2016 at 17:29, James Bottomley
>>> <James.Bottomley@hansenpartnership.com> wrote:
..
>> Not really. The point is that you've proposed something as an addition
>> to the kernel that can also be done in userspace. Checking if it can
>> work easily there is like a barrier to entry. If it works, then fine,
>> we're done. If it throws up problems then we reconsider the kernel
>> route.
hdparm has full support for the SANITIZE commands in userspace.
-ml
^ permalink raw reply
* Re: [GIT PULL] libata fixes for v4.9-rc2
From: David Howells @ 2016-10-26 22:17 UTC (permalink / raw)
To: Tejun Heo, Linus Torvalds; +Cc: dhowells, hch, linux-ide, linux-kernel
In-Reply-To: <20161026182911.GB23927@htj.duckdns.org>
> The AHCI MSI handling change in rc1 was a bit broken and caused disk
> probing failures on some machines. These three patches should fix the
> issues.
My test machine fell foul of this using a PCIe M.2-attached SSD card.
The patches fix it for me.
Tested-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* [GIT PULL] libata fixes for v4.9-rc2
From: Tejun Heo @ 2016-10-26 18:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-ide, linux-kernel
Hello, Linus.
The AHCI MSI handling change in rc1 was a bit broken and caused disk
probing failures on some machines. These three patches should fix the
issues.
Thanks.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.9-fixes
for you to fetch changes up to 0ce57f8af1782fd12d3a81872a4ab97244989802:
ahci: fix the single MSI-X case in ahci_init_one (2016-10-25 11:43:07 -0400)
----------------------------------------------------------------
Christoph Hellwig (3):
ahci: only try to use multi-MSI mode if there is more than 1 port
ahci: fix nvec check
ahci: fix the single MSI-X case in ahci_init_one
drivers/ata/ahci.c | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
--
tejun
^ permalink raw reply
* Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-10-26 17:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, Dmitry Eremin-Solenikov,
linux-kernel, linux-ide, Olof Johansson, Kevin Hilman,
Nori, Sekhar
In-Reply-To: <4264651.gPKphdYuCx@wuerfel>
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).
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
https://github.com/bzolnier/linux.git v4.9-rc2-arm-configs-pata
for you to fetch changes up to bc9c6cc857849ec0d83bd13c1812bae9345dc553:
arm: spitz_defconfig: convert to use libata PATA drivers (2016-10-26 18:43:33 +0200)
----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (16):
arm: assabet_defconfig: disable IDE subsystem
arm: badge4_defconfig: disable IDE subsystem
arm: cerfcube_defconfig: disable IDE subsystem
arm: lart_defconfig: disable IDE subsystem
arm: mainstone_defconfig: disable IDE subsystem
arm: shannon_defconfig: disable IDE subsystem
arm: collie_defconfig: convert to use libata PATA drivers
arm: omap1_defconfig: convert to use libata PATA drivers
arm: am200epdkit_defconfig: convert to use libata PATA drivers
arm: corgi_defconfig: convert to use libata PATA drivers
arm: h3600_defconfig: convert to use libata PATA drivers
arm: ixp4xx_defconfig: convert to use libata PATA drivers
arm: jornada720_defconfig: convert to use libata PATA drivers
arm: netwinder_defconfig: convert to use libata PATA drivers
arm: s3c2410_defconfig: convert to use libata PATA drivers
arm: spitz_defconfig: convert to use libata PATA drivers
arch/arm/configs/am200epdkit_defconfig | 5 +++--
arch/arm/configs/assabet_defconfig | 1 -
arch/arm/configs/badge4_defconfig | 2 --
arch/arm/configs/cerfcube_defconfig | 1 -
arch/arm/configs/collie_defconfig | 5 +++--
arch/arm/configs/corgi_defconfig | 7 +++----
arch/arm/configs/h3600_defconfig | 5 +++--
arch/arm/configs/ixp4xx_defconfig | 9 +++++----
arch/arm/configs/jornada720_defconfig | 5 +++--
arch/arm/configs/lart_defconfig | 2 --
arch/arm/configs/mainstone_defconfig | 1 -
arch/arm/configs/netwinder_defconfig | 7 ++++---
arch/arm/configs/omap1_defconfig | 4 ++--
arch/arm/configs/s3c2410_defconfig | 10 +++-------
arch/arm/configs/shannon_defconfig | 1 -
arch/arm/configs/spitz_defconfig | 8 +++-----
16 files changed, 32 insertions(+), 41 deletions(-)
^ permalink raw reply
* [PATCH v3 1/1] ahci: imx: Add imx53 SATA temperature sensor support
From: Fabien Lahoudere @ 2016-10-25 20:08 UTC (permalink / raw)
To: tj
Cc: linux-ide, linux-kernel, rui.zhang, edubezval, Csaba Kertesz,
Fabien Lahoudere
In-Reply-To: <2364981.7VqghJWO9f@amdc3058>
From: Csaba Kertesz <csaba.kertesz@vincit.fi>
Add a hwmon entry to get the temperature from the die of imx53
SATA.
The original patch was made by Richard Zhu for kernel 2.6.x:
ENGR00134041-MX53-Add-the-SATA-AHCI-temperature-monitor.patch
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
---
drivers/ata/ahci_imx.c | 195 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 195 insertions(+)
diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 3f3a7db..420f065 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -26,6 +26,9 @@
#include <linux/mfd/syscon.h>
#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
#include <linux/libata.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/thermal.h>
#include "ahci.h"
#define DRV_NAME "ahci-imx"
@@ -214,6 +217,180 @@ static int imx_sata_phy_reset(struct ahci_host_priv *hpriv)
return timeout ? 0 : -ETIMEDOUT;
}
+enum {
+ /* SATA PHY Register */
+ SATA_PHY_CR_CLOCK_CRCMP_LT_LIMIT = 0x0001,
+ SATA_PHY_CR_CLOCK_DAC_CTL = 0x0008,
+ SATA_PHY_CR_CLOCK_RTUNE_CTL = 0x0009,
+ SATA_PHY_CR_CLOCK_ADC_OUT = 0x000A,
+ SATA_PHY_CR_CLOCK_MPLL_TST = 0x0017,
+};
+
+static int read_adc_sum(void *dev, u16 rtune_ctl_reg, void __iomem * mmio)
+{
+ u16 adc_out_reg, read_sum;
+ u32 index, read_attempt;
+ const u32 attempt_limit = 100;
+
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+ imx_phy_reg_write(rtune_ctl_reg, mmio);
+
+ /* two dummy read */
+ index = 0;
+ read_attempt = 0;
+ adc_out_reg = 0;
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_ADC_OUT, mmio);
+ while (index < 2) {
+ imx_phy_reg_read(&adc_out_reg, mmio);
+ /* check if valid */
+ if (adc_out_reg & 0x400)
+ index++;
+
+ read_attempt++;
+ if (read_attempt > attempt_limit) {
+ dev_err(dev, "Read REG more than %d times!\n",
+ attempt_limit);
+ break;
+ }
+ }
+
+ index = 0;
+ read_attempt = 0;
+ read_sum = 0;
+ while (index < 80) {
+ imx_phy_reg_read(&adc_out_reg, mmio);
+ if (adc_out_reg & 0x400) {
+ read_sum = read_sum + (adc_out_reg & 0x3FF);
+ index++;
+ }
+ read_attempt++;
+ if (read_attempt > attempt_limit) {
+ dev_err(dev, "Read REG more than %d times!\n",
+ attempt_limit);
+ break;
+ }
+ }
+
+ /* Use the U32 to make 1000 precision */
+ return (read_sum * 1000) / 80;
+}
+
+/* SATA AHCI temperature monitor */
+static int sata_ahci_read_temperature(void *dev, int *temp)
+{
+ u16 mpll_test_reg, rtune_ctl_reg, dac_ctl_reg, read_sum;
+ u32 str1, str2, str3, str4;
+ int m1, m2, a;
+ struct ahci_host_priv *hpriv = dev_get_drvdata(dev);
+ void __iomem *mmio = hpriv->mmio;
+
+ /* check rd-wr to reg */
+ read_sum = 0;
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_CRCMP_LT_LIMIT, mmio);
+ imx_phy_reg_write(read_sum, mmio);
+ imx_phy_reg_read(&read_sum, mmio);
+ if ((read_sum & 0xffff) != 0)
+ dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+ imx_phy_reg_write(0x5A5A, mmio);
+ imx_phy_reg_read(&read_sum, mmio);
+ if ((read_sum & 0xffff) != 0x5A5A)
+ dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+ imx_phy_reg_write(0x1234, mmio);
+ imx_phy_reg_read(&read_sum, mmio);
+ if ((read_sum & 0xffff) != 0x1234)
+ dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+ /* start temperature test */
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+ imx_phy_reg_read(&mpll_test_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+ imx_phy_reg_read(&rtune_ctl_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+ imx_phy_reg_read(&dac_ctl_reg, mmio);
+
+ /* mpll_tst.meas_iv ([12:2]) */
+ str1 = (mpll_test_reg >> 2) & 0x7FF;
+ /* rtune_ctl.mode ([1:0]) */
+ str2 = (rtune_ctl_reg) & 0x3;
+ /* dac_ctl.dac_mode ([14:12]) */
+ str3 = (dac_ctl_reg >> 12) & 0x7;
+ /* rtune_ctl.sel_atbp ([4]) */
+ str4 = (rtune_ctl_reg >> 4);
+
+ /* Calculate the m1 */
+ /* mpll_tst.meas_iv */
+ mpll_test_reg = (mpll_test_reg & 0xE03) | (512) << 2;
+ /* rtune_ctl.mode */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFFC) | (1);
+ /* dac_ctl.dac_mode */
+ dac_ctl_reg = (dac_ctl_reg & 0x8FF) | (4) << 12;
+ /* rtune_ctl.sel_atbp */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFEF) | (0) << 4;
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+ imx_phy_reg_write(mpll_test_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+ imx_phy_reg_write(dac_ctl_reg, mmio);
+ m1 = read_adc_sum(dev, rtune_ctl_reg, mmio);
+
+ /* Calculate the m2 */
+ /* rtune_ctl.sel_atbp */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFEF) | (1) << 4;
+ m2 = read_adc_sum(dev, rtune_ctl_reg, mmio);
+
+ /* restore the status */
+ /* mpll_tst.meas_iv */
+ mpll_test_reg = (mpll_test_reg & 0xE03) | (str1) << 2;
+ /* rtune_ctl.mode */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFFC) | (str2);
+ /* dac_ctl.dac_mode */
+ dac_ctl_reg = (dac_ctl_reg & 0x8FF) | (str3) << 12;
+ /* rtune_ctl.sel_atbp */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFEF) | (str4) << 4;
+
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+ imx_phy_reg_write(mpll_test_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+ imx_phy_reg_write(dac_ctl_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+ imx_phy_reg_write(rtune_ctl_reg, mmio);
+
+ /* Compute temperature */
+ if (!(m2 / 1000))
+ m2 = 1000;
+ a = (m2 - m1) / (m2/1000);
+ *temp = ((-559) * a * a) / 1000 + (1379) * a + (-458000);
+
+ return 0;
+}
+
+static ssize_t sata_ahci_show_temp(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ unsigned int temp = 0;
+ int err;
+
+ err = sata_ahci_read_temperature(dev, &temp);
+ if (err < 0)
+ return err;
+
+ return sprintf(buf, "%u\n", temp);
+}
+
+static const struct thermal_zone_of_device_ops fsl_sata_ahci_of_thermal_ops = {
+ .get_temp = sata_ahci_read_temperature,
+};
+
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, sata_ahci_show_temp, NULL, 0);
+
+static struct attribute *fsl_sata_ahci_attrs[] = {
+ &sensor_dev_attr_temp1_input.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(fsl_sata_ahci);
+
static int imx_sata_enable(struct ahci_host_priv *hpriv)
{
struct imx_ahci_priv *imxpriv = hpriv->plat_data;
@@ -597,6 +774,24 @@ static int imx_ahci_probe(struct platform_device *pdev)
if (ret)
return ret;
+ if (imxpriv->type == AHCI_IMX53) {
+ /* Add the temperature monitor */
+ struct device *hwmon_dev;
+
+ hwmon_dev =
+ devm_hwmon_device_register_with_groups(dev,
+ "sata_ahci",
+ hpriv,
+ fsl_sata_ahci_groups);
+ if (IS_ERR(hwmon_dev)) {
+ ret = PTR_ERR(hwmon_dev);
+ goto disable_clk;
+ }
+ devm_thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
+ &fsl_sata_ahci_of_thermal_ops);
+ dev_info(dev, "%s: sensor 'sata_ahci'\n", dev_name(hwmon_dev));
+ }
+
ret = imx_sata_enable(hpriv);
if (ret)
goto disable_clk;
--
2.1.4
^ permalink raw reply related
* (unknown),
From: mariobronti @ 2016-10-25 17:17 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: EMAIL_26515359826_linux-ide.zip --]
[-- Type: application/zip, Size: 5747 bytes --]
^ permalink raw reply
* Re: [PATCH] ahci: fix the single MSI-X case in ahci_init_one
From: Tejun Heo @ 2016-10-25 15:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide, rrichter, ddaney.cavm
In-Reply-To: <1477397074-26799-1-git-send-email-hch@lst.de>
On Tue, Oct 25, 2016 at 02:04:34PM +0200, Christoph Hellwig wrote:
> We need to make sure hpriv->irq is set properly if we don't use per-port
> vectors, so switch from blindly assigning pdev->irq to using
> pci_irq_vector, which handles all interrupt types correctly.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reported-by: Robert Richter <robert.richter@cavium.com>
> Tested-by: Robert Richter <robert.richter@cavium.com>
> Tested-by: David Daney <ddaney.cavm@gmail.com>
> Fixes: 0b9e2988ab22 ("ahci: use pci_alloc_irq_vectors")
Applied to libata/for-4.9-fixes.
Thanks.
--
tejun
^ 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