Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
On Mon, 2019-03-04 at 20:45 +0100, Paul Gevers wrote: > Hi, > > On Sun, 24 Feb 2013 07:08:14 + Ben Hutchings > wrote: > > > "Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI > > ID 8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU > > functionality can be disabled for the GPU by adding the kernel > > parameter 'intel_iommu=igfx_off'." > > This bug is marked as affecting the release-notes. I don't think this is > still relevant for stretch or buster? If not, I'll like to remove the > "affects", to not clutter the release-notes bug list. This should have been included in release notes, and I don't think the issue has been solved, but at this point it's probably pointless to mention it. Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson signature.asc Description: This is a digitally signed message part
Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
Hi, On Sun, 24 Feb 2013 07:08:14 + Ben Hutchings wrote: > "Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI > ID 8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU > functionality can be disabled for the GPU by adding the kernel > parameter 'intel_iommu=igfx_off'." This bug is marked as affecting the release-notes. I don't think this is still relevant for stretch or buster? If not, I'll like to remove the "affects", to not clutter the release-notes bug list. Paul PS: please CC me, I am not subscribed to this bug. signature.asc Description: OpenPGP digital signature
Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
Le 24/02/2013 17:30, Ben Hutchings a écrit : On Sun, 2013-02-24 at 17:13 +0100, Pierre AUSSAGUEL wrote: Le 24/02/2013 08:08, Ben Hutchings a écrit : [...] If we can't come up with a workaround, this should be mentioned in the release notes to prevent a regression on upgrade. Please feel free to remind me in that case so I can come up with some wording (though I also wouldn't mind if someone else does). Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI ID 8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU functionality can be disabled for the GPU by adding the kernel parameter 'intel_iommu=igfx_off'. Do you want that I test with intel_iommu=igfx_off in 3.7, or even in 3.2 ? Do you want that I test too intel_iommu=off in 3.2 ? For now, the system works well with 3.7 but that would be better to use a stable kernel for sure ! Please test intel_iommu=igfx_off in both 3.7 and the 3.2+drm kernel linked from http://bugs.debian.org/687442#131. (The next upload to unstable will include those drm changes.) Ben. I have made a few tests : 3.7 + intel_iommu=igfx_off - problem still here (no messages at all) 3.2 + intel_iommu=igfx_off - problem still here (not sure about missing IRQ messages) 3.2 + intel_iommu=off - problem still here (with missing IRQ messages) 3.2+drm + intel_iommu=off - problem still here (with missing IRQ messages) The only stable solution (using gnome shell of course) is 3.7 + intel_iommu=off -- Pierre AUSSAGUEL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
Le 24/02/2013 08:08, Ben Hutchings a écrit :
On Sat, 2013-02-23 at 12:05 -0800, Jonathan Nieder wrote:
found 697029 linux/3.7.3-1~experimental.1
tags 697029 - wontfix
affects 697029 + release-notes
quit
Hi,
Chris Wilson wrote:
The performance issue on 3.7 is not due to the missed irq, but a
combination of using UXA and VT-d. In order to workaround an erratum
on Ironlake, every time we touch the GPU's page tables, we have to
idle the GPU before doing so. This causes extremely noticeable display
lag.
For reference, the workaround seems to be implemented by:
commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
Author: David Woodhouse dw...@infradead.org
Date: Sun Sep 25 19:11:14 2011 -0700
intel-iommu: Workaround IOTLB hang on Ironlake GPU
commit 5c0422878fcdc279ae9a8e8b66972a15b5efb67f
Author: Ben Widawsky b...@bwidawsk.net
Date: Mon Oct 17 15:51:55 2011 -0700
drm/i915: ILK + VT-d workaround
However the latter is applied only to Ironlake M (mobile). So either
there are two different bugs or there is some confusion about which
chips have the bug.
Pierre AUSSAGUEL wrote:
Appending intel_iommu=off seems to fix the problem (I tested a few
days befor posting).
Daniel Vetter wrote:
Since we can't fix the hw, closing this as wontfix. Thanks for
reporting this issue anyway.
That makes this a distro issue, I suppose.
Ben and X team, any ideas? Would it makes sense to disable
intel_iommu by default on this hardware and require intel_iommu=on to
reenable it?
Use of an IOMMU is in part a performance vs security trade-off. I tend
to think that security settings should have consistent defaults, as
otherwise users may assume that a security feature is enabled when it is
not.
Aside from that, the Intel IOMMU can be enabled separately per device
(except behind PCI bridges). Since IGPs aren't real PCI(e) devices and
Intel has not always validated their interaction with the IOMMU, they
often don't work with it. There is already a kernel parameter to
disable it for the IGP ('intel_iommu=igfx_off') and a quirk to do so
automatically for the G4x and GM45. Maybe the thing to do is to log a
message about this parameter when enabling the workaround for Ironlake.
Should GNOME somehow detect that it should use classic
mode by default when the iommu is enabled?
I think this would be a very poor heuristic.
If we can't come up with a workaround, this should be mentioned in the
release notes to prevent a regression on upgrade. Please feel free to
remind me in that case so I can come up with some wording (though I
also wouldn't mind if someone else does).
Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI ID
8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU functionality can
be disabled for the GPU by adding the kernel parameter
'intel_iommu=igfx_off'.
Do you want that I test with intel_iommu=igfx_off in 3.7, or even in 3.2 ?
Do you want that I test too intel_iommu=off in 3.2 ?
For now, the system works well with 3.7 but that would be better to use
a stable kernel for sure !
(The identification of which devices are affected may need to be
revised.)
Ben.
--
Pierre AUSSAGUEL
ACHROME photographies : http://achrome.eu/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
On Sun, 2013-02-24 at 17:13 +0100, Pierre AUSSAGUEL wrote: Le 24/02/2013 08:08, Ben Hutchings a écrit : [...] If we can't come up with a workaround, this should be mentioned in the release notes to prevent a regression on upgrade. Please feel free to remind me in that case so I can come up with some wording (though I also wouldn't mind if someone else does). Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI ID 8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU functionality can be disabled for the GPU by adding the kernel parameter 'intel_iommu=igfx_off'. Do you want that I test with intel_iommu=igfx_off in 3.7, or even in 3.2 ? Do you want that I test too intel_iommu=off in 3.2 ? For now, the system works well with 3.7 but that would be better to use a stable kernel for sure ! Please test intel_iommu=igfx_off in both 3.7 and the 3.2+drm kernel linked from http://bugs.debian.org/687442#131. (The next upload to unstable will include those drm changes.) Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
found 697029 linux/3.7.3-1~experimental.1 tags 697029 - wontfix affects 697029 + release-notes quit Hi, Chris Wilson wrote: The performance issue on 3.7 is not due to the missed irq, but a combination of using UXA and VT-d. In order to workaround an erratum on Ironlake, every time we touch the GPU's page tables, we have to idle the GPU before doing so. This causes extremely noticeable display lag. Pierre AUSSAGUEL wrote: Appending intel_iommu=off seems to fix the problem (I tested a few days befor posting). Daniel Vetter wrote: Since we can't fix the hw, closing this as wontfix. Thanks for reporting this issue anyway. That makes this a distro issue, I suppose. Ben and X team, any ideas? Would it makes sense to disable intel_iommu by default on this hardware and require intel_iommu=on to reenable it? Should GNOME somehow detect that it should use classic mode by default when the iommu is enabled? If we can't come up with a workaround, this should be mentioned in the release notes to prevent a regression on upgrade. Please feel free to remind me in that case so I can come up with some wording (though I also wouldn't mind if someone else does). Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
On Sat, 2013-02-23 at 12:05 -0800, Jonathan Nieder wrote:
found 697029 linux/3.7.3-1~experimental.1
tags 697029 - wontfix
affects 697029 + release-notes
quit
Hi,
Chris Wilson wrote:
The performance issue on 3.7 is not due to the missed irq, but a
combination of using UXA and VT-d. In order to workaround an erratum
on Ironlake, every time we touch the GPU's page tables, we have to
idle the GPU before doing so. This causes extremely noticeable display
lag.
For reference, the workaround seems to be implemented by:
commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
Author: David Woodhouse dw...@infradead.org
Date: Sun Sep 25 19:11:14 2011 -0700
intel-iommu: Workaround IOTLB hang on Ironlake GPU
commit 5c0422878fcdc279ae9a8e8b66972a15b5efb67f
Author: Ben Widawsky b...@bwidawsk.net
Date: Mon Oct 17 15:51:55 2011 -0700
drm/i915: ILK + VT-d workaround
However the latter is applied only to Ironlake M (mobile). So either
there are two different bugs or there is some confusion about which
chips have the bug.
Pierre AUSSAGUEL wrote:
Appending intel_iommu=off seems to fix the problem (I tested a few
days befor posting).
Daniel Vetter wrote:
Since we can't fix the hw, closing this as wontfix. Thanks for
reporting this issue anyway.
That makes this a distro issue, I suppose.
Ben and X team, any ideas? Would it makes sense to disable
intel_iommu by default on this hardware and require intel_iommu=on to
reenable it?
Use of an IOMMU is in part a performance vs security trade-off. I tend
to think that security settings should have consistent defaults, as
otherwise users may assume that a security feature is enabled when it is
not.
Aside from that, the Intel IOMMU can be enabled separately per device
(except behind PCI bridges). Since IGPs aren't real PCI(e) devices and
Intel has not always validated their interaction with the IOMMU, they
often don't work with it. There is already a kernel parameter to
disable it for the IGP ('intel_iommu=igfx_off') and a quirk to do so
automatically for the G4x and GM45. Maybe the thing to do is to log a
message about this parameter when enabling the workaround for Ironlake.
Should GNOME somehow detect that it should use classic
mode by default when the iommu is enabled?
I think this would be a very poor heuristic.
If we can't come up with a workaround, this should be mentioned in the
release notes to prevent a regression on upgrade. Please feel free to
remind me in that case so I can come up with some wording (though I
also wouldn't mind if someone else does).
Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI ID
8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU functionality can
be disabled for the GPU by adding the kernel parameter
'intel_iommu=igfx_off'.
(The identification of which devices are affected may need to be
revised.)
Ben.
--
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
signature.asc
Description: This is a digitally signed message part
