All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mihai Moldovan <ionic@ionic.de>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: i915-related and general system freezes with specific kernel config // IOMMU
Date: Tue, 22 Jan 2013 19:15:05 +0100	[thread overview]
Message-ID: <50FED729.8020405@ionic.de> (raw)
In-Reply-To: <50FD84E0.2090901@ionic.de>


[-- Attachment #1.1.1: Type: text/plain, Size: 1178 bytes --]

* On 21.01.2013 07:11 PM, Mihai Moldovan wrote:
> I'm also currently testing a kernel without the Intel IOMMU feature
> [CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least
> not seeing USB and PCI(e) issues. I'll leave the box running for some
> more [time] [...]

No freezes for >22h, seems to be fine.


> [...] and will afterwards disable IOMMU as a whole to see if I hit
> USB and PCI(e) issues again with that combination.

The systems seems to run stable with CONFIG_IOMMU_SUPPORT=n set, too. This is
expected.
However: unlike during earlier tests when I disabled IOMMU and Intel IOMMU via
kernel/boot parameters, I am not seeing any DMA mapping errors.

There seems to be a difference between disabling IOMMU/Intel IOMMU statically in
the kernel compared to disabling it via kernel parameter. Is this another bug?

I've attached both kernel ring buffer logs (minus the timings for easier diffing.)

  [*] kern-new-iommu_off.log.bz2 disables IOMMU and Intel IOMMU via boot parameter
  [*] kern-iommu_static_off.log.bz2 has CONFIG_IOMMU_SUPPORT=n set and any IOMMU
support statically disabled (also consequently DMAR)



Mihai


[-- Attachment #1.1.2: kern-new-iommu_off.log.bz2 --]
[-- Type: application/x-bzip2, Size: 16365 bytes --]

[-- Attachment #1.1.3: kern-iommu_static_off.log.bz2 --]
[-- Type: application/x-bzip2, Size: 16854 bytes --]

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4506 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Mihai Moldovan <ionic@ionic.de>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: LKML <linux-kernel@vger.kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: i915-related and general system freezes with specific kernel config // IOMMU
Date: Tue, 22 Jan 2013 19:15:05 +0100	[thread overview]
Message-ID: <50FED729.8020405@ionic.de> (raw)
In-Reply-To: <50FD84E0.2090901@ionic.de>


[-- Attachment #1.1: Type: text/plain, Size: 1178 bytes --]

* On 21.01.2013 07:11 PM, Mihai Moldovan wrote:
> I'm also currently testing a kernel without the Intel IOMMU feature
> [CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least
> not seeing USB and PCI(e) issues. I'll leave the box running for some
> more [time] [...]

No freezes for >22h, seems to be fine.


> [...] and will afterwards disable IOMMU as a whole to see if I hit
> USB and PCI(e) issues again with that combination.

The systems seems to run stable with CONFIG_IOMMU_SUPPORT=n set, too. This is
expected.
However: unlike during earlier tests when I disabled IOMMU and Intel IOMMU via
kernel/boot parameters, I am not seeing any DMA mapping errors.

There seems to be a difference between disabling IOMMU/Intel IOMMU statically in
the kernel compared to disabling it via kernel parameter. Is this another bug?

I've attached both kernel ring buffer logs (minus the timings for easier diffing.)

  [*] kern-new-iommu_off.log.bz2 disables IOMMU and Intel IOMMU via boot parameter
  [*] kern-iommu_static_off.log.bz2 has CONFIG_IOMMU_SUPPORT=n set and any IOMMU
support statically disabled (also consequently DMAR)



Mihai


[-- Attachment #1.2: kern-new-iommu_off.log.bz2 --]
[-- Type: application/x-bzip2, Size: 16365 bytes --]

[-- Attachment #1.3: kern-iommu_static_off.log.bz2 --]
[-- Type: application/x-bzip2, Size: 16854 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4506 bytes --]

  reply	other threads:[~2013-01-22 18:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-18 23:48 i915-related and general system freezes with specific kernel config // IOMMU Mihai Moldovan
2013-01-18 23:59 ` Mihai Moldovan
2013-01-19 13:27 ` Daniel Vetter
2013-01-19 16:13   ` Mihai Moldovan
2013-01-19 16:25     ` Daniel Vetter
2013-01-19 16:26     ` Mihai Moldovan
2013-01-19 16:30       ` Daniel Vetter
2013-01-19 16:30         ` Daniel Vetter
2013-01-20 21:52   ` Mihai Moldovan
2013-01-20 22:49     ` Daniel Vetter
2013-01-21 18:11       ` Mihai Moldovan
2013-01-22 18:15         ` Mihai Moldovan [this message]
2013-01-22 18:15           ` Mihai Moldovan
2013-01-22 18:52           ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50FED729.8020405@ionic.de \
    --to=ionic@ionic.de \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.