On Wed, 2014-04-09 at 22:03 -0600, Bjorn Helgaas wrote:
[+cc Joerg, iommu list]
On Wed, Apr 9, 2014 at 6:19 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote:
On Wed, 2014-04-09 at 16:40 -0700, Davidlohr Bueso wrote:
On Wed, 2014-04-09
[+ David, VT-d maintainer ]
Jiang, David, can you please have a look into this issue?
Thanks,
Joerg
On Wed, Apr 09, 2014 at 11:32:37PM -0700, Davidlohr Bueso wrote:
On Wed, 2014-04-09 at 22:03 -0600, Bjorn Helgaas wrote:
[+cc Joerg, iommu list]
On Wed, Apr 9, 2014 at 6:19 PM,
Hi Baoquan,
Could you please help to give output of lspci -?
Is device hpsa :03:00.0 a legacy PCI device(non-PCIe)?
It may have relationship with IOMMU driver.
Thanks!
Gerry
On 2014/4/10 12:03, Bjorn Helgaas wrote:
[+cc Joerg, iommu list]
On Wed, Apr 9, 2014 at 6:19 PM,
On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote:
[+ David, VT-d maintainer ]
Jiang, David, can you please have a look into this issue?
DMAR:[fault reason 02] Present bit in context entry is clear
dmar: DRHD: handling fault status reg 602
dmar: DMAR:[DMA Read]
On Wed, Apr 09, 2014 at 10:23:32AM -0600, Jens Axboe wrote:
This should go into block/blk-mq-tag.h.
Ok.
We might as well leave this, the mtip32xx conversion ends up using it. So
if we pull it now, it'll just be reintroduced shortly.
It's back in the latest revision of the patch, just taking
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
dmesg had the usual
[ 215.229903] usb 4-2: usb_disable_lpm called, do nothing
[ 215.336941] usb 4-2: reset SuperSpeed USB device number 3 using
static int
ch_release(struct inode *inode, struct file *file)
{
scsi_changer *ch = file-private_data;
scsi_device_put(ch-device);
+ ch-device = NULL;
file-private_data = NULL;
+ kref_put(ch-ref, ch_destroy);
Any reason you need to put the scsi_device here
Only your 0/3 patch to which Alan linked, along with two other patches
by Mathias Nyman (disable usb3 on intel hosts and disable all lpm
related control transfers, one of which is the source of the do
nothings).
I'll revert the latter two and apply the rest of the set. Which I'm
guessing
On 04/10/2014 02:26 PM, Andreas Reis wrote:
Only your 0/3 patch to which Alan linked, along with two other
patches by Mathias Nyman (disable usb3 on intel hosts and disable
all lpm related control transfers, one of which is the source of
the do nothings).
I'll revert the latter two and
Wir bieten privaten und gewerblichen Darlehen ohne Sicherheiten (nur
Identifikation) bei 3% Zinssatz, ab € 10.000 bis € 90.000.000 in 1 Jahr
bis 20 Jahren Laufzeit überall in der Welt..
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to
On 04/10/2014 01:51 PM, Christoph Hellwig wrote:
static int
ch_release(struct inode *inode, struct file *file)
{
scsi_changer *ch = file-private_data;
scsi_device_put(ch-device);
+ch-device = NULL;
file-private_data = NULL;
+kref_put(ch-ref, ch_destroy);
Any
2014-04-06 22:33 GMT+02:00 Michael Schmitz schmitz...@gmail.com:
Hello Dave, Tuomas,
Also, looking at the timeout formulae in the old NCR53C9x.c driver,
the values would be different for FAS216. Why was this dropped from
the modern esp_scsi?
I've never seen a formula for any ESP or
There is an error with the medium access timeout feature of the sd driver. The
sdkp-medium_access_timed_out value is reset to zero in sd_done() in the wrong
place. Currently it is reset to zero only when a command returns sense data.
This can result in cases where the medium access check falsely
On Thu, Apr 10, 2014 at 2:46 AM, Woodhouse, David
david.woodho...@intel.com wrote:
DMAR:[fault reason 02] Present bit in context entry is clear
dmar: DRHD: handling fault status reg 602
dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr
7f61e000
That
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
dmesg had the usual
[ 215.229903] usb 4-2: usb_disable_lpm called, do nothing
[ 215.336941]
On 4/10/2014 11:14 AM, Bjorn Helgaas wrote:
On Thu, Apr 10, 2014 at 2:46 AM, Woodhouse, David
david.woodho...@intel.com wrote:
DMAR:[fault reason 02] Present bit in context entry is clear
dmar: DRHD: handling fault status reg 602
dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr
On Thu, 2014-04-10 at 09:14 -0600, Bjorn Helgaas wrote:
Thus, my first guess would be that we are quite happily setting up the
requested DMA maps on the *wrong* IOMMU, and then taking faults when the
device actually tries to do DMA.
I like the wrong IOMMU (or no IOMMU at all) theory. If
On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote:
dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr
7f61e000
That Present bit in context entry is clear fault means that we have
not set up *any* mappings for this PCI device… on this IOMMU.
Yes,
On 04/10/2014 05:31 PM, Alan Stern wrote:
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
dmesg had the usual
[ 215.229903] usb 4-2: usb_disable_lpm
On 04/09/2014 01:32 PM, Nathan Fontenot wrote:
Update the MAINTAINERS file to indicate the current maintainers
for the IBM Power 842 Compression driver, IBM Power Virtual SCSI
driver and the IBM Power Virtual FC Driver.
Signed-off-by: Nathan Fontenot nf...@linux.vnet.ibm.com
---
Acked-by:
On Thu, 2014-04-10 at 19:52 +0200, Hannes Reinecke wrote:
On 04/10/2014 05:31 PM, Alan Stern wrote:
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
On Wed, Apr 09, 2014 at 11:32:37PM -0700, Davidlohr Bueso wrote:
On Wed, 2014-04-09 at 22:03 -0600, Bjorn Helgaas wrote:
[+cc Joerg, iommu list]
On Wed, Apr 9, 2014 at 6:19 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote:
On Wed,
On Thu, Apr 10, 2014 at 04:20:46PM -0500, scame...@beardog.cce.hp.com wrote:
On Thu, Apr 10, 2014 at 02:53:30PM -0600, Bjorn Helgaas wrote:
[subject changed]
On Thu, Apr 10, 2014 at 2:45 PM, scame...@beardog.cce.hp.com wrote:
On Wed, Apr 09, 2014 at 11:32:37PM -0700, Davidlohr Bueso
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index
On Thu, 2014-04-10 at 17:17 -0500, scame...@beardog.cce.hp.com wrote:
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
So I'm not surprised that this patch doesn't solve the problem I am
seeing with DMAR and the hpsa driver hard lockup.
In any case it should
On Thu, Apr 10, 2014 at 2:45 PM, scame...@beardog.cce.hp.com wrote:
3f583bc21977 BAD (Merge tag 'iommu-updates-v3.15')
Yes, specifically (finally done bisecting):
commit 2e45528930388658603ea24d49cf52867b928d3e
Author: Jiang Liu jiang@linux.intel.com
Date: Wed Feb 19 14:07:36 2014
Hi Linus,
James might still be in the process of sending this your way. However,
given the proximity to -rc1, my reasoning for sending this directly is:
1/ It provides a tangible speed up for a non-esoteric use case (laptop
resume):
On 04/10/14 at 04:34pm, Jiang Liu wrote:
Hi Baoquan,
Could you please help to give output of lspci -?
Is device hpsa :03:00.0 a legacy PCI device(non-PCIe)?
It may have relationship with IOMMU driver.
Thanks!
Gerry
Hi,
I just saw your mail now. Do you still need the output of
Hello Kars,
I've never seen a formula for any ESP or FAS chip for the timeout
other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192
factor being used in the old NCR53C9x driver.
I haven't gone far enough back in the 53C9x
On 2014-04-10 04:01, Christoph Hellwig wrote:
On Wed, Apr 09, 2014 at 10:23:32AM -0600, Jens Axboe wrote:
This should go into block/blk-mq-tag.h.
Ok.
We might as well leave this, the mtip32xx conversion ends up using it. So
if we pull it now, it'll just be reintroduced shortly.
It's back
This patch works for me.
Tested-by: Baoquan He b...@redhat.com
Thanks
Baoquan
On 04/10/14 at 05:17pm, scame...@beardog.cce.hp.com wrote:
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
On 04/10/14 at 04:34pm, Jiang Liu wrote:
Hi Baoquan,
Could you please help to give output of lspci -?
Is device hpsa :03:00.0 a legacy PCI device(non-PCIe)?
It may have relationship with IOMMU driver.
Thanks!
Gerry
Well, the machine bug was reported on is a AMD machine, and it
Hi James,
While building a recent kernel with -Werror I found this warning:
drivers/scsi/aic94xx/aic94xx_sds.c: In function 'asd_read_flash':
drivers/scsi/aic94xx/aic94xx_sds.c:597:21: error: 'offs' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
On 04/10/2014 10:36 PM, James Bottomley wrote:
On Thu, 2014-04-10 at 19:52 +0200, Hannes Reinecke wrote:
On 04/10/2014 05:31 PM, Alan Stern wrote:
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes,
34 matches
Mail list logo
