On Wed, 2020-11-18 at 23:51 +0700, Suravee Suthikulpanit wrote:
> Yes, this fixes the issue. Now I can receive the IOMMU event log
> interrupts for IO_PAGE_FAULT event, which is triggered
> using the injection interface via debugfs.
Thanks, Suravee.
smime.p7s
Description: S/MIME cryptographic
Tglx,
On 11/18/20 9:06 PM, Thomas Gleixner wrote:
Suravee,
On Wed, Nov 18 2020 at 17:29, Suravee Suthikulpanit wrote:
On 11/17/20 9:00 AM, Suravee Suthikulpanit wrote:
I might need your help debugging this issue. I'm seeing the following error:
[ 14.005937] irq 29, desc: d200500b,
Suravee,
On Wed, Nov 18 2020 at 17:29, Suravee Suthikulpanit wrote:
> On 11/17/20 9:00 AM, Suravee Suthikulpanit wrote:
>
> I might need your help debugging this issue. I'm seeing the following error:
>
> [ 14.005937] irq 29, desc: d200500b, depth: 0, count: 0, unhandled: > 0
> [
On Wed, 2020-11-18 at 17:29 +0700, Suravee Suthikulpanit wrote:
> I might need your help debugging this issue. I'm seeing the following error:
>
> [ 14.005937] irq 29, desc: d200500b, depth: 0, count: 0, unhandled: > 0
> [ 14.006234] ->handle_irq(): eab4b6eb,
David
On 11/17/20 9:00 AM, Suravee Suthikulpanit wrote:
David,
On 11/13/20 10:14 PM, David Woodhouse wrote:
On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote:
I had trouble cloning your tree for some reason, so just took the top
three patches and applied them to the tip tree. This all
David,
On 11/13/20 10:14 PM, David Woodhouse wrote:
On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote:
I had trouble cloning your tree for some reason, so just took the top
three patches and applied them to the tip tree. This all appears to be
working. I'll let the IOMMU experts take a
On Fri, 2020-11-13 at 15:14 +, David Woodhouse wrote:
> On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote:
> > I had trouble cloning your tree for some reason, so just took the top
> > three patches and applied them to the tip tree. This all appears to be
> > working. I'll let the IOMMU
On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote:
> I had trouble cloning your tree for some reason, so just took the top
> three patches and applied them to the tip tree. This all appears to be
> working. I'll let the IOMMU experts take a closer look (adding Suravee).
Thanks. I see Thomas
On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote:
> On 11/11/20 6:32 AM, David Woodhouse wrote:
> > On Wed, 2020-11-11 at 10:36 +, David Woodhouse wrote:
> > > On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote:
> > > > Looking at it now with brain awake, the XTSUP stuff is pretty
On 11/11/20 6:32 AM, David Woodhouse wrote:
> On Wed, 2020-11-11 at 10:36 +, David Woodhouse wrote:
>> On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote:
>>> Looking at it now with brain awake, the XTSUP stuff is pretty much
>>> the same as DMAR, which I didn't realize yesterday. The
On Wed, 2020-11-11 at 10:36 +, David Woodhouse wrote:
> On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote:
> > Looking at it now with brain awake, the XTSUP stuff is pretty much
> > the same as DMAR, which I didn't realize yesterday. The affinity
> > notifier muck is not needed when we
On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote:
> Looking at it now with brain awake, the XTSUP stuff is pretty much
> the same as DMAR, which I didn't realize yesterday. The affinity
> notifier muck is not needed when we have a write_msg() function which
> twiddles the bits into those
On Wed, Nov 11 2020 at 08:16, David Woodhouse wrote:
> On Tue, 2020-11-10 at 23:48 +0100, Thomas Gleixner wrote:
>> + * IRQCHIP_MSI_EXTID The MSI message created for this chip
>> can
>> + * have an otherwise forbidden extended ID
>
> If we're
On Tue, 2020-11-10 at 23:48 +0100, Thomas Gleixner wrote:
> + * IRQCHIP_MSI_EXTID The MSI message created for this chip
> can
> + * have an otherwise forbidden extended ID
If we're going to do that then we could ditch the separate
On 11/10/20 4:48 PM, Thomas Gleixner wrote:
> On Tue, Nov 10 2020 at 16:00, Tom Lendacky wrote:
>> On 11/10/20 3:30 PM, David Woodhouse wrote:
>> [ 15.581115] WARNING: CPU: 6 PID: 1 at arch/x86/kernel/apic/apic.c:2527
>> __irq_msi_compose_msg+0x9f/0xb0
>> [ 15.581115] Call Trace:
>> [
On Tue, Nov 10 2020 at 16:00, Tom Lendacky wrote:
> On 11/10/20 3:30 PM, David Woodhouse wrote:
> [ 15.581115] WARNING: CPU: 6 PID: 1 at arch/x86/kernel/apic/apic.c:2527
> __irq_msi_compose_msg+0x9f/0xb0
> [ 15.581115] Call Trace:
> [ 15.581115] irq_msi_update_msg+0x4d/0x80
> [
On 11/10/20 3:30 PM, David Woodhouse wrote:
>
>
> On 10 November 2020 21:01:17 GMT, Thomas Gleixner wrote:
>> On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote:
>>
>>> On 10 November 2020 18:56:17 GMT, Thomas Gleixner
>> wrote:
On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
>
On 10 November 2020 21:01:17 GMT, Thomas Gleixner wrote:
>On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote:
>
>> On 10 November 2020 18:56:17 GMT, Thomas Gleixner
> wrote:
>>>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>
On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote:
> On 10 November 2020 18:56:17 GMT, Thomas Gleixner wrote:
>>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
>>> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
If I could get post-5.5 kernels to boot at all with the AMD IOMMU
On 10 November 2020 18:56:17 GMT, Thomas Gleixner wrote:
>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
>> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>>> If I could get post-5.5 kernels to boot at all with the AMD IOMMU
>>> enabled, I'd have a go at throwing that together
On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>> If I could get post-5.5 kernels to boot at all with the AMD IOMMU
>> enabled, I'd have a go at throwing that together now...
>
> It can share the dmar domain code. Let me frob something.
On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
> On Tue, 2020-11-10 at 10:17 -0600, Tom Lendacky wrote:
>> Yep. The warning started triggering with:
>> 47bea873cf80 ("x86/msi: Only use high bits of MSI address for DMAR unit")
>>
>> Here's the backtrace:
>>
>> [ 15.745929]
On 11/10/20 10:33 AM, David Woodhouse wrote:
> On Tue, 2020-11-10 at 10:17 -0600, Tom Lendacky wrote:
>> Yep. The warning started triggering with:
>> 47bea873cf80 ("x86/msi: Only use high bits of MSI address for DMAR unit")
>>
>> Here's the backtrace:
>>
>> [ 15.611109] [ cut here
On Tue, 2020-11-10 at 10:17 -0600, Tom Lendacky wrote:
> Yep. The warning started triggering with:
> 47bea873cf80 ("x86/msi: Only use high bits of MSI address for DMAR unit")
>
> Here's the backtrace:
>
> [ 15.611109] [ cut here ]
> [ 15.616274] WARNING: CPU: 184 PID:
On Tue, 2020-11-10 at 16:54 +0100, Thomas Gleixner wrote:
> On Tue, Nov 10 2020 at 08:55, Tom Lendacky wrote:
> > On 11/10/20 8:34 AM, Thomas Gleixner wrote:
> > I was about to send the dmesg output when I saw this. A quick test
> > with
> > this change resolves the boot issue, thanks!
>
> /me
On Mon, 2020-11-09 at 17:15 -0600, Tom Lendacky wrote:
> On 10/29/20 7:15 AM, tip-bot2 for Thomas Gleixner wrote:
> > The following commit has been merged into the x86/apic branch of tip:
> >
> > Commit-ID: a27dca645d2c0f31abb7858aa0e10b2fa0f2f659
> > Gitweb:
> >
26 matches
Mail list logo
