[+ 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
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
> > > >> >
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 taki
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 xhci_hcd
[ 215.350296] xhci_hcd :00:14.0: xHC
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 us
> 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
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
nothing"s).
I'll revert the latter two and apply the rest of the set. Which I'm
guessin
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 nothing"s).
>
> I'll revert the latter t
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 majord...
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->r
2014-04-06 22:33 GMT+02:00 Michael Schmitz :
>
> 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 FAS chi
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
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
>> > > >> > > > > 7f61e0
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
> > [ 2
On 4/10/2014 11:14 AM, Bjorn Helgaas wrote:
> On Thu, Apr 10, 2014 at 2:46 AM, Woodhouse, David
> 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] faul
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)" th
On Thu, 2014-04-10 at 16:34 +0800, Jiang Liu wrote:
> Hi Baoquan,
> Could you please help to give output of "lspci -"?
Attached.
> Is device "hpsa :03:00.0" a legacy PCI device(non-PCIe)?
> It may have relationship with IOMMU driver.
I honestly don't know. PCI is way out of my area
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… o
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 cal
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
> ---
Acked-by: Brian King
--
Br
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 appeara
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 wrote:
> > > On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote:
> > >> On Wed, 2014
[subject changed]
On Thu, Apr 10, 2014 at 2:45 PM, wrote:
> 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 wrote:
>> > > On Wed, 20
On Thu, Apr 10, 2014 at 02:53:30PM -0600, Bjorn Helgaas wrote:
> [subject changed]
>
> On Thu, Apr 10, 2014 at 2:45 PM, wrote:
> > 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 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, wrote:
> > > On Wed, Apr 09, 2014 at 11:32:37PM -0700, Davidlohr Bueso wrote:
> > >> On Wed
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
Signed-off-by: Stephen M. Cameron
---
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 8cf4a0c..ef4dfdd 100644
---
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 shoul
On Thu, Apr 10, 2014 at 2:45 PM, wrote:
>> > 3f583bc21977 BAD ("Merge tag 'iommu-updates-v3.15'")
>>
>> Yes, specifically (finally done bisecting):
>>
>> commit 2e45528930388658603ea24d49cf52867b928d3e
>> Author: Jiang Liu
>> Date: Wed Feb 19 14:07:36 2014 +0800
>>
>> iommu/vt-d: Unify the
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):
https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-
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
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 i
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 i
This patch works for me.
Tested-by: Baoquan He
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
> ---
> drivers/scsi/hpsa.c |4
>
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 machin
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]
drivers/scsi/aic94xx/aic9
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
>-Original Message-
>From: Geert Uytterhoeven [mailto:ge...@linux-m68k.org]
>Sent: Tuesday, March 25, 2014 2:07 AM
>To: Jiri Kosina
>Cc: linux-ker...@vger.kernel.org; Geert Uytterhoeven; DL-MegaRAID Linux;
>linux-scsi@vger.kernel.org
>Subject: [PATCH trivial 1/3] megaraid_sas: Spelling s/
>-Original Message-
>From: Rashika Kheria [mailto:rashika.khe...@gmail.com]
>Sent: Saturday, March 29, 2014 11:47 PM
>To: linux-ker...@vger.kernel.org
>Cc: DL-MegaRAID Linux; James E.J. Bottomley; linux-scsi@vger.kernel.org;
>j...@joshtriplett.org
>Subject: [PATCH 29/55] scsi: Mark functi
>-Original Message-
>From: Rashika Kheria [mailto:rashika.khe...@gmail.com]
>Sent: Saturday, March 29, 2014 11:48 PM
>To: linux-ker...@vger.kernel.org
>Cc: DL-MegaRAID Linux; James E.J. Bottomley; linux-scsi@vger.kernel.org;
>j...@joshtriplett.org
>Subject: [PATCH 30/55] scsi: Mark functi
>-Original Message-
>From: Rashika Kheria [mailto:rashika.khe...@gmail.com]
>Sent: Sunday, March 30, 2014 12:18 AM
>To: linux-ker...@vger.kernel.org
>Cc: DL-MegaRAID Linux; James E.J. Bottomley; linux-scsi@vger.kernel.org;
>j...@joshtriplett.org
>Subject: [PATCH 51/55] scsi: Move prototyp
>-Original Message-
>From: Rashika Kheria [mailto:rashika.khe...@gmail.com]
>Sent: Sunday, March 30, 2014 12:19 AM
>To: linux-ker...@vger.kernel.org
>Cc: DL-MegaRAID Linux; James E.J. Bottomley; linux-scsi@vger.kernel.org;
>j...@joshtriplett.org
>Subject: [PATCH 52/55] scsi: Move prototyp
42 matches
Mail list logo
