Prev: avoid return NULL on root rb_node in rb_next/rb_prev in lib/rbtree.c
Next: arch/x86/kernel/cpu/mtrr/cleanup.c: Use ";" not "," to terminate statements
From: Dan Williams on 1 Jul 2010 13:30
On 7/1/2010 1:15 AM, Woodhouse, David wrote:
> On Thu, 2010-07-01 at 08:26 +0100, Williams, Dan J wrote:
>> On 7/1/2010 12:12 AM, Woodhouse, David wrote:
>>> On Thu, 2010-07-01 at 07:51 +0100, Williams, Dan J wrote:
>>>> This version of the device only exists on the 5400 chipset and always
>>>> has its own iommu, but since other platforms get the DMAR entry right I
>>>> think this hammer is too big? Wouldn't this break VT-d operation on
>>>> non-busted platforms?
>>>
>>> That just means we have to get the quirk right. Does 'this version' of
>>> the device have its own PCI ID? We can always fall back to checking the
>>> ID of the device at 0000:00:00.0 to check which chipset we're on.
>>>
>>
>> PCI_DEVICE_ID_INTEL_IOAT_SNB only exists on this chipset
>
> Something like this, then?
>

Thanks David!

Chris, attached is a combined patch with David's catch for the VT-d
misconfiguration, and some code to more gracefully handle this init
failure in the driver. Can you see if this resolves the problem?
(remove the prior patches I have sent).

Thanks,
Dan

From: Chris Li on 1 Jul 2010 14:10
On Thu, Jul 1, 2010 at 10:20 AM, Dan Williams <dan.j.williams(a)intel.com> wrote:
> Chris, attached is a combined patch with David's catch for the VT-d
> misconfiguration, and some code to more gracefully handle this init failure
> in the driver. �Can you see if this resolves the problem? (remove the prior
> patches I have sent).

Thanks for the patch. I will test that and get back to you today.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Chris Li on 2 Jul 2010 15:10
On Thu, Jul 1, 2010 at 10:58 AM, Chris Li <lkml(a)chrisli.org> wrote:
> On Thu, Jul 1, 2010 at 10:20 AM, Dan Williams <dan.j.williams(a)intel.com> wrote:
>> Chris, attached is a combined patch with David's catch for the VT-d
>> misconfiguration, and some code to more gracefully handle this init failure
>> in the driver.  Can you see if this resolves the problem? (remove the prior
>> patches I have sent).
>
> Thanks for the patch. I will test that and get back to you today.

Sorry lost my machine last night again so I did not complete the test yesterday.

modprobe ioatmda did not crash any more:

ioatdma: Intel(R) QuickData Technology Driver 4.00
ioatdma 0000:00:0f.0: can't derive routing for PCI INT A
ioatdma 0000:00:0f.0: PCI INT A: no GSI
ioatdma 0000:00:0f.0: setting latency timer to 64
alloc irq_desc for 57 on node -1
alloc kstat_irqs on node -1
ioatdma 0000:00:0f.0: irq 57 for MSI/MSI-X
alloc irq_desc for 58 on node -1
alloc kstat_irqs on node -1
ioatdma 0000:00:0f.0: irq 58 for MSI/MSI-X
alloc irq_desc for 59 on node -1
alloc kstat_irqs on node -1
ioatdma 0000:00:0f.0: irq 59 for MSI/MSI-X
alloc irq_desc for 60 on node -1
alloc kstat_irqs on node -1
ioatdma 0000:00:0f.0: irq 60 for MSI/MSI-X
ioatdma 0000:00:0f.0: failed to start channel chanerr: 0x10
ioatdma 0000:00:0f.0: Freeing 1 in use descriptors!
ioatdma 0000:00:0f.0: selftest cannot allocate chan resource
ioatdma 0000:00:0f.0: Intel(R) I/OAT DMA Engine init failed
ioatdma 0000:00:0f.0: can't derive routing for PCI INT A

But I don't see the line that print out BIOS is lying.

Attach the full dmesg again here.

Chris
From: David Woodhouse on 5 Jul 2010 06:20
On Fri, 2010-07-02 at 20:00 +0100, Chris Li wrote:
> But I don't see the line that print out BIOS is lying.

Hrm. Want to augment the dmar_find_matched_drhd_unit() function to
_always_ print the DRHD returned for the offending PCI device? And if
that still doesn't show, make it print pdev->vendor, pdev->device and
the returned DRHD pointer for _every_ call?

--
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Chris Li on 6 Jul 2010 19:50
On Mon, Jul 5, 2010 at 3:16 AM, David Woodhouse <dwmw2(a)infradead.org> wrote:
> On Fri, 2010-07-02 at 20:00 +0100, Chris Li wrote:
>> But I don't see the line that print out BIOS is lying.
>
> Hrm. Want to augment the dmar_find_matched_drhd_unit() function to
> _always_ print the DRHD returned for the offending PCI device? And if
> that still doesn't show, make it print pdev->vendor, pdev->device and
> the returned DRHD pointer for _every_ call?

I just did some experiment, my PCI device ID is PCI_DEVICE_ID_INTEL_ESB2_0
(0x2670) instead of PCI_DEVICE_ID_INTEL_IOAT_SNB.

That seems to be the reason preventing the warning to be print out. I am not
sure the warning should be always print out. Just curious why it did
not trigger.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: avoid return NULL on root rb_node in rb_next/rb_prev in lib/rbtree.c
Next: arch/x86/kernel/cpu/mtrr/cleanup.c: Use ";" not "," to terminate statements