Re: [Lsf] [TOPIC] scsi-queue tree past and future
On Thu, 2015-03-05 at 06:48 -0800, James Bottomley wrote: > On Thu, 2015-03-05 at 14:31 +0100, Christoph Hellwig wrote: > > For about 8 month I've merged almost every scsi commit through the > > scsi-queue staging tree, and it seems to have worked out well enough. > > > > I've been too busy for the next cycle, so 4.1 will probably have to live > > without it. I'd like to get feedback on how the tree worked for > > contributors > > and driver maintainers, and brainstorm how to move forward with it, > > preferably > > some form of real team maintainance that avoids single points of failure. > > I'd like to thank Christoph for doing this, it's been an enormous help. > > Here's what we'll do for 4.1: I need all the current Maintainers to > collect the patches and reviews in their area and send them to the list > as a series. We'll be adhering to the guidelines Christoph laid down > for inclusion: > > - the patch needs at least two positive reviews (non-author signoff, >reviewed-by or acked-by tags). In practice this means it had at >least one and I added another one. >As an exception I also take trivial and important fixes if they >only have a Tested-by: instead of a second review. > - the patch has no negative review on the mailing list > - the patch applies cleanly > - the patch compiles (drivers for architectures I can't test excluded) > - for core the core branch: the patch survives a full xfstests run This should be pretty standard in all subsystems, no? And I know this has been discussed many times, but I see no reason not to also consider trinity -- which has a tendency of kicking you in the nuts when you least expect it to. At least in MM we are trying to be a bit more proactive about this, perhaps Sasha or Dave would disagree with me ;) But in general it would also help other subsystems. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lsf] [TOPIC] scsi-queue tree past and future
On Fri, 2015-03-06 at 20:43 -0800, James Bottomley wrote: > Well, to clarify what's happening: I'm not running the tests, I asked > the 0 day kernel testing project to run them on all the patches in my > tree. The 0 day project has a bunch of standard tests for all trees and > then some optional ones (like xfstests) which I asked Fengguang to turn > on in our case. > > Trinity is part of the 0 day project tests, so I could ask for it to be > turned on too, Oh, I was not aware of that. I tend to consider LTP something completely unrelated. > but I'm not sure it would be so useful for SCSI: trinity > is a sys call fuzzing tool but the sys call exposure of SCSI is pretty > tiny. xfstests, which exercise the filesystem data above us provide a > much wider range of testing. Yeah I'm really talking at a generic level, just like LTP. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote: > On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote: > > [+linux-scsi] > > On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote: > > > On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote: > > > > Hi, > > > > > > > > The kernel is 3.14.0+ which is pulled just now. > > > > > > Cc'ing more people. > > > > > > While the hpsa driver appears to be involved in some way, I'm sure if > > > this is a related issue, but as of today's pull I'm getting another > > > problem that causes my DL980 not to come up. > > > > > > *Massive* amounts of: > > > > > > 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 > > > > > > Then: > > > > > > hpsa :03:00.0: Controller lockup detected: 0x > > > ... > > > Workqueue: events hpsa_monitor_ctlr_worker [hpsa] > > > ... > > > > > > Screenshot of the actual LOCKUP: > > > http://stgolabs.net/hpsa-hard-lockup-3.14+.png > > > > > > While I haven't bisected, things worked fine until at least until commit > > > 39de65aa2c3e (April 2nd). > > > > > > Any ideas? > > > > Well, it's either a DMA remapping issue or a hpsa one. Your assertion > > that everything worked fine until 39de65aa2c3e would tend to vindicate > > hpsa, Hmm here you mean DMA, right? > because all the hpsa changes went in before that under > Missing crucial info: > > commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1 > > > Merge: 3e75c6d b2bff6c > > Author: Linus Torvalds > > Date: Tue Apr 1 18:49:04 2014 -0700 > > > > Merge tag 'scsi-misc' of > > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi > > > > can you revalidate that this commit works OK just to make sure? Ok so I don't see those DMA messages and system starts just fine. I'm thinking perhaps something broke after the IO mmu stuff in commit 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly causing the CPU stalls and just blame hpsa in the path as a side effect? /me goes out to try the commit. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
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 at 16:10 -0700, James Bottomley wrote: > > > On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote: > > > > [+linux-scsi] > > > > On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote: > > > > > On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote: > > > > > > Hi, > > > > > > > > > > > > The kernel is 3.14.0+ which is pulled just now. > > > > > > > > > > Cc'ing more people. > > > > > > > > > > While the hpsa driver appears to be involved in some way, I'm sure if > > > > > this is a related issue, but as of today's pull I'm getting another > > > > > problem that causes my DL980 not to come up. > > > > > > > > > > *Massive* amounts of: > > > > > > > > > > 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 > > > > > > > > > > Then: > > > > > > > > > > hpsa :03:00.0: Controller lockup detected: 0x > > > > > ... > > > > > Workqueue: events hpsa_monitor_ctlr_worker [hpsa] > > > > > ... > > > > > > > > > > Screenshot of the actual LOCKUP: > > > > > http://stgolabs.net/hpsa-hard-lockup-3.14+.png > > > > > > > > > > While I haven't bisected, things worked fine until at least until > > > > > commit > > > > > 39de65aa2c3e (April 2nd). > > > > > > > > > > Any ideas? > > > > > > > > Well, it's either a DMA remapping issue or a hpsa one. Your assertion > > > > that everything worked fine until 39de65aa2c3e would tend to vindicate > > > > hpsa, > > > > Hmm here you mean DMA, right? > > No, it vindicates the hpsa changes ... they don't seem to be causing > problems until something goes wrong with dma remapping. > > > > because all the hpsa changes went in before that under > > > Missing crucial info: > > > > > > commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1 > > > > > > > Merge: 3e75c6d b2bff6c > > > > Author: Linus Torvalds > > > > Date: Tue Apr 1 18:49:04 2014 -0700 > > > > > > > > Merge tag 'scsi-misc' of > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi > > > > > > > > can you revalidate that this commit works OK just to make sure? > > > > Ok so I don't see those DMA messages and system starts just fine. I'm > > thinking perhaps something broke after the IO mmu stuff in commit > > 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly > > causing the CPU stalls and just blame hpsa in the path as a side effect? > > > > /me goes out to try the commit. > > That's my guess. The DMAR messages are DMA remapping issues caused in > the IOMMU. If I had to guess, I'd say the DMAR fault message is > indicating the IOMMU is calling for a mapping address before it can > satisfy the driver read request, which is causing the hang apparently in > the hpsa driver. > > I've added linux-pci to the cc; I think they deal with iommu issues on > x86. So that merge commit appears to be the culprit, I see both the DMA messages and the lockup blaming hpsa... -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
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-04-09 at 16:40 -0700, Davidlohr Bueso wrote:
> >> > On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote:
> >> > > On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote:
> >> > > > [+linux-scsi]
> >> > > > On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote:
> >> > > > > On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote:
> >> > > > > > Hi,
> >> > > > > >
> >> > > > > > The kernel is 3.14.0+ which is pulled just now.
> >> > > > >
> >> > > > > Cc'ing more people.
> >> > > > >
> >> > > > > While the hpsa driver appears to be involved in some way, I'm sure
> >> > > > > if
> >> > > > > this is a related issue, but as of today's pull I'm getting another
> >> > > > > problem that causes my DL980 not to come up.
> >> > > > >
> >> > > > > *Massive* amounts of:
> >> > > > >
> >> > > > > 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
> >> > > > >
> >> > > > > Then:
> >> > > > >
> >> > > > > hpsa :03:00.0: Controller lockup detected: 0x
> >> > > > > ...
> >> > > > > Workqueue: events hpsa_monitor_ctlr_worker [hpsa]
> >> > > > > ...
> >> > > > >
> >> > > > > Screenshot of the actual LOCKUP:
> >> > > > > http://stgolabs.net/hpsa-hard-lockup-3.14+.png
> >> > > > >
> >> > > > > While I haven't bisected, things worked fine until at least until
> >> > > > > commit
> >> > > > > 39de65aa2c3e (April 2nd).
> >> > > > >
> >> > > > > Any ideas?
> >> > > >
> >> > > > Well, it's either a DMA remapping issue or a hpsa one. Your
> >> > > > assertion
> >> > > > that everything worked fine until 39de65aa2c3e would tend to
> >> > > > vindicate
> >> > > > hpsa,
> >> >
> >> > Hmm here you mean DMA, right?
> >>
> >> No, it vindicates the hpsa changes ... they don't seem to be causing
> >> problems until something goes wrong with dma remapping.
> >>
> >> > > because all the hpsa changes went in before that under
> >> > > Missing crucial info:
> >> > >
> >> > > commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1
> >> > >
> >> > > > Merge: 3e75c6d b2bff6c
> >> > > > Author: Linus Torvalds
> >> > > > Date: Tue Apr 1 18:49:04 2014 -0700
> >> > > >
> >> > > > Merge tag 'scsi-misc' of
> >> > > > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> >> > > >
> >> > > > can you revalidate that this commit works OK just to make sure?
> >> >
> >> > Ok so I don't see those DMA messages and system starts just fine. I'm
> >> > thinking perhaps something broke after the IO mmu stuff in commit
> >> > 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly
> >> > causing the CPU stalls and just blame hpsa in the path as a side effect?
> >> >
> >> > /me goes out to try the commit.
> >>
> >> That's my guess. The DMAR messages are DMA remapping issues caused in
> >> the IOMMU. If I had to guess, I'd say the DMAR fault message is
> >> indicating the IOMMU is calling for a mapping address before it can
> >> satisfy the driver read request, which is causing the hang apparently in
> >> the hpsa driver.
> >>
> >> I've added linux-pci to the cc; I think they deal with iommu issues on
> >> x86.
> >
> > So that merge commit appears to be the culprit, I see both the DMA
> > messages and the lockup blaming hpsa...
>
> My understanding so far (please correct me if I'm wrong):
>
> 39de65aa2c3e OK ("Merge branch 'i2c/for-next'")
> 1a0b6abaea78 OK ("Merge tag 'scsi-misc'")
> 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 way to process DMAR device scope array
Now we have a PCI bus notification based mechanism to update DMAR
device scope array, we could extend the mechanism to support boot
time initialization too, which will help to unify and simplify
the implementation.
Signed-off-by: Jiang Liu
Signed-off-by: Joerg Roedel
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
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 of knowledge. 00:00.0 Host bridge: Intel Corporation 5520/5500/X58 I/O Hub to ESI Port (rev 22) Subsystem: Hewlett-Packard Company Device 330b Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:02.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 2 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:04.0 PCI bridge: Intel Corporation 5520/X58 I/O Hub PCI Express Root Port 4 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:05.0 PCI bridge: Intel Corporation 5520/X58 I/O Hub PCI Express Root Port 5 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:06.0 PCI bridge: Intel Corporation 5520/X58 I/O Hub PCI Express Root Port 6 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:08.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 8 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:09.0 PCI bridge: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 9 (rev 22) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- Dis
Re: [PATCH] hpsa: fix uninitialized trans_support in hpsa_put_ctlr_into_performant_mode()
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 address Baoquan's original report, so it confirms that it is in fact two different sets of issues. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
Sorry for the delay, I've been having to take turns for this box. On Fri, 2014-04-11 at 09:18 +, Woodhouse, David wrote: > On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote: > > Attaching a dmesg from one of the kernels that boots. It doesn't appear > > to have much of the related information... is there any debug config > > option I can enable that might give you more data? > > I'd like the contents of /sys/firmware/acpi/tables/DMAR please. Attached is the disassembly of the raw output. > And > please could you also apply this patch to both the last-working and > first-failing kernels and show me the output in both cases? So I still cannot get around getting the info for the first failing kernel, but below is for the last working. Thanks. Device 0:03:00.0 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.1 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.3 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.4 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.4 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.7 [0x7f7ee000 - 0x7f7e] Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 IOMMU: Prepare 0-16MiB unity mapping for LPC IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff] Device 0:00:1f.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O Device 0:00:00.0 on IOMMU at a800 Device 0:00:01.0 on IOMMU at a800 Device 0:00:02.0 on IOMMU at a800 Device 0:00:03.0 on IOMMU at a800 Device 0:00:04.0 on IOMMU at a800 Device 0:00:05.0 on IOMMU at a800 Device 0:00:06.0 on IOMMU at a800 Device 0:00:07.0 on IOMMU at a800 Device 0:00:08.0 on IOMMU at a800 Device 0:00:09.0 on IOMMU at a800 Device 0:00:0a.0 on IOMMU at a800 Device 0:00:14.0 on IOMMU at a800 Device 0:00:1c.0 on IOMMU at a800 Device 0:00:1c.4 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1e.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 Device 0:04:00.0 on IOMMU at a800 Device 0:04:00.1 on IOMMU at a800 Device 0:04:00.2 on IOMMU at a800 Device 0:04:00.3 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 Device 0:01:03.0 on IOMMU at a800 Device 0:50:00.0 on IOMMU at ac00 Device 0:50:01.0 on IOMMU at ac00 Device 0:50:02.0 on IOMMU at ac00 Device 0:50:03.0 on IOMMU at ac00 Device 0:50:04.0 on IOMMU at ac00 Device 0:50:05.0 on IOMMU at ac00 Device 0:50:06.0 on IOMMU at ac00 Device 0:50:07.0 on IOMMU at ac00 Device 0:50:08.0 on IOMMU at ac00 Device 0:50:09.0 on IOMMU at ac00 Device 0:50:0a.0 on IOMMU at ac00 Device 0:50:14.0 on IOMMU at a800 Device 0:a0:00.0 on IOMMU at b000 Device 0:a0:01.0 on IOMMU at b000 Device 0:a0:02.0 on IOMMU at b000 Device 0:a0:03.0 on IOMMU at b000 Device 0:a0:04.0 on IOMMU at b000 Device 0:a0:05.0 on IOMMU at b000 Device 0:a0:06.0 on IOMMU at b000 Device 0:a0:07.0 on IOMMU at b000 Device 0:a0:08.0 on IOMMU at b000 Device 0:a0:09.0 on IOMMU at b000 Device 0:a0:0a.0 on IOMMU at b000 Device 0:a0:14.0 on IOMMU at a800 Device 0:7c:00.0 on IOMMU at a800 Device 0:7c:08.0 on IOMMU at a800 Device 0:82:00.0 on IOMMU at a800 Device 0:82:08.0 on IOMMU at a800 /* * Intel ACPI Component Architecture * AML Disassembler version 20140325-64 [Apr 11 2014] * Copyright (c) 2000 - 2014 Intel Corporation * * Disassembly of DMAR.raw, F
Re: hpsa driver bug crack kernel down!
On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: > Hi Davidlohr, > Thanks for providing the DMAR table. According to the DMAR > table, one bug in the iommu driver fails to handle this entry: > [1D2h 0466 1] Device Scope Entry Type : 01 > [1D3h 0467 1] Entry Length : 0A > [1D4h 0468 2] Reserved : > [1D6h 0470 1] Enumeration ID : 00 > [1D7h 0471 1] PCI Bus Number : 00 > [1D8h 0472 2] PCI Path : 1C,04 > [1DAh 0474 2] PCI Path : 00,02 > > And the patch sent out by me should fix this bug. Could you please help > to have a try? Sorry, I am unable to find any patches from you regarding this issue... I must be missing something. Could you please point me to the lkml link? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
On Mon, 2014-04-14 at 09:44 -0700, Davidlohr Bueso wrote: > On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: > > Hi Davidlohr, > > Thanks for providing the DMAR table. According to the DMAR > > table, one bug in the iommu driver fails to handle this entry: > > [1D2h 0466 1] Device Scope Entry Type : 01 > > [1D3h 0467 1] Entry Length : 0A > > [1D4h 0468 2] Reserved : > > [1D6h 0470 1] Enumeration ID : 00 > > [1D7h 0471 1] PCI Bus Number : 00 > > [1D8h 0472 2] PCI Path : 1C,04 > > [1DAh 0474 2] PCI Path : 00,02 > > > > And the patch sent out by me should fix this bug. Could you please help > > to have a try? > > Sorry, I am unable to find any patches from you regarding this issue... > I must be missing something. Could you please point me to the lkml link? Never mind, I got it internally. I'll let you know as soon as I can test it later today. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
On Mon, 2014-04-14 at 16:57 +0800, Jiang Liu wrote: > Hi all, > I guess I found the root cause. It's a bug in matching > device scope, variable 'level' should be decreased when walking up PCI > topology. > Could you please help to test following patch? > Thanks! > Gerry Worked like a charm -- I no longer see all those DMAR messages and the hpsa hard lockup is gone, thanks. Feel free to add my: Reported-and-tested-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] block: provide helpers for reading block count
On Thu, 23 Jun 2016, Arnd Bergmann wrote: Several drivers use an expensive do_div() to compute the number of logical or physical blocks in a blockdev, which can be done more efficiently using a shift, since the blocksize is always a power of two number. Let's introduce bdev_logical_block_count() and bdev_physical_block_count() helper functions mirroring the bdev_logical_block_size() and bdev_physical_block_size() interfaces for the block size. @@ -1226,6 +1226,13 @@ static inline unsigned short bdev_logical_block_size(struct block_device *bdev) return queue_logical_block_size(bdev_get_queue(bdev)); } +static inline sector_t bdev_logical_block_count(struct block_device *bdev) Curious, why not just return u64 instead for all these instead of sector_t (ie dealing with lba, it reads weird)? Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3
On Fri, 30 Nov 2018, Kees Cook wrote: On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen wrote: In order to comply with the CoC, replace with a hug. I hope this is some kind of joke. How would anyone get offended by reading technical comments? This is all beyond me... Thanks, Davidlohr
