* [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
* [PATCH] ahci: fix the single MSI-X case in ahci_init_one
From: Christoph Hellwig @ 2016-10-25 12:04 UTC (permalink / raw)
To: tj; +Cc: linux-ide, rrichter, ddaney.cavm
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")
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index ba5f11c..5fe852d 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
/* legacy intx interrupts */
pci_intx(pdev, 1);
}
- hpriv->irq = pdev->irq;
+ hpriv->irq = pci_irq_vector(pdev, 0);
if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
host->flags |= ATA_HOST_PARALLEL_SCAN;
^ permalink raw reply related
* Re: [PATCH] ahci: use pci_alloc_irq_vectors
From: Robert Richter @ 2016-10-25 9:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robert Richter, Auger Eric, Marc Zyngier, linux-ide,
dan.j.williamps, Tejun Heo, linux-arm-kernel
In-Reply-To: <20161022141123.GA25500@lst.de>
On 22.10.16 16:11:23, Christoph Hellwig wrote:
> Hi Robert,
>
> is this a controller that's using MSI-X?
>
> If so can you try the patch below?
Great, that fixes the issue. Thanks.
Tested-by: Robert Richter <rrichter@cavium.com>
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index ba5f11c..5fe852d 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> /* legacy intx interrupts */
> pci_intx(pdev, 1);
> }
> - hpriv->irq = pdev->irq;
> + hpriv->irq = pci_irq_vector(pdev, 0);
>
> if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> host->flags |= ATA_HOST_PARALLEL_SCAN;
^ permalink raw reply
* Re: [PATCH 0/5] ahci: nvme remap support
From: Dan Williams @ 2016-10-24 21:01 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Keith Busch, Tejun Heo, IDE/ATA development list, linux-nvme
In-Reply-To: <20161024175527.GA11088@lst.de>
On Mon, Oct 24, 2016 at 10:55 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Oct 24, 2016 at 10:46:29AM -0700, Dan Williams wrote:
>> On Mon, Oct 24, 2016 at 8:16 AM, Christoph Hellwig <hch@lst.de> wrote:
>> > On Mon, Oct 24, 2016 at 10:46:29AM -0400, Keith Busch wrote:
>> >> Amber is aware of this and was supportive in having Intel open the
>> >> specs to enable this hardware.
>> >
>> > Ok, let's get the spec out first.
>>
>> The patch contents are it.
>
> Well. that's simply not acceptable. We will need a theory of
> operation for this device to support it, because the patch as-is
> simply doesn't make sense.
The presence of ahci bar remapping is documented here:
http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html
The PCI memory space is remapped, the configuration space of the
remapped device is not available, and interrupts are shared.
> We'll also need to know where such device might show up, and why
> Linux support for it matters.
This is a capability of the "Intel® 100 Series Chipset Family". These
patches matter because this chipset in this configuration appears in
laptops that you can buy today and Linux is unable to access the NVMe
device.
>> > Do we expect to be able to use the
>> > AHCI interface and the NVMe interface at the same time?
>>
>> Yes, simultaneous access.
>
> Yikes. I'm really tempted to say this is not acceptable - Intel
> really must know better.
>
Linux users are unable to access storage without these patches.
>> That said, the driver seems to already comprehend instances where the
>> device does not support nvme_reset_subsystem() requests. I don't know
>> how often those resets need to be issued in practice.
>
> It's not about how often reset are needed (and there are controller
> resets in addition to function level resets), but how they are
> defined to work. What state is a controller in after a host initiated
> reset, after a PCIe hotplug or even warm plug. What state is the
> PCI device in when the controller is in a failed state?
Talking with Keith, subsystem-resets are a feature of enterprise-class
NVMe devices. I think those features are out of scope for the class
of devices that will find themselves in a platform with this
configuration, same for hot-plug.
>> > If it's the latter let's keep AHCI entirely out
>> > of the game - add the affected PCI IDs to the NVMe driver itself, add
>> > a quirk for them and implement the enable sequence inside the NVMe
>> > driver.
>>
>> The PCI ID of the AHCI device is not uniquely identifiable when in this mode.
>>
>> We could flip the arrangement and have the ahci device as the platform
>> device, but I'm not sure this makes the nvme reset problem much
>> better. If we allow subsystem resets at all they would still need to
>> be coordinated across 2 devices/drivers to reinitialize pci registers.
>
> I think the simple answer is to not support this device. It's not like
> Intel doesn't know the AHCI and NVMe specs and had any reaoson to come
> up with a piece of junk like this.
Whatever answer we, in the Linux kernel community, come up with,
leaving storage inaccessible is not an acceptable answer.
^ permalink raw reply
* Re: [PATCH] ahci: use pci_alloc_irq_vectors
From: David Daney @ 2016-10-24 20:29 UTC (permalink / raw)
To: Christoph Hellwig, Robert Richter
Cc: Auger Eric, Marc Zyngier, linux-ide, Robert Richter,
dan.j.williamps, Tejun Heo, linux-arm-kernel
In-Reply-To: <20161022141123.GA25500@lst.de>
On 10/22/2016 07:11 AM, Christoph Hellwig wrote:
> Hi Robert,
>
> is this a controller that's using MSI-X?
>
> If so can you try the patch below?
>
After better understanding your request, I applied this against:
http://git.kernel.org/cgit/linux/kernel/git/tj/libata.git/log/?h=for-4.9-fixes
(commit a478b097474cd9f2268ab1beaca74ff09e652b9b)
This is now working on my ThunderX CRB-2S system.
You can add:
Tested-by: David Daney <david.daney@cavium.com>
Thanks for taking the time to work through this.
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index ba5f11c..5fe852d 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> /* legacy intx interrupts */
> pci_intx(pdev, 1);
> }
> - hpriv->irq = pdev->irq;
> + hpriv->irq = pci_irq_vector(pdev, 0);
>
> if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> host->flags |= ATA_HOST_PARALLEL_SCAN;
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ 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