-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29/03/12 13:39, Daniel Vetter wrote:
> Is the for-chainsaw branch plus intel_iommu=igfx_off now stable for
> you?
It appears to crash when I shut my machine down, but has otherwise
behaved quite well.
Regards,
- --
Tony Vroon
UNIX systems adminis
On Wed, Mar 28, 2012 at 09:55:09AM +0100, Tony Vroon wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 27/03/12 21:39, Daniel Vetter wrote:
> > Yet another thing to try: Can you append intel_iommu=igfx_off to
> > your kernel cmdline? If you can, try this both on mainline kernels
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29/03/12 13:39, Daniel Vetter wrote:
> Is the for-chainsaw branch plus intel_iommu=igfx_off now stable for
> you?
It appears to crash when I shut my machine down, but has otherwise
behaved quite well.
Regards,
- --
Tony Vroon
UNIX systems adminis
On Wed, Mar 28, 2012 at 09:55:09AM +0100, Tony Vroon wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 27/03/12 21:39, Daniel Vetter wrote:
> > Yet another thing to try: Can you append intel_iommu=igfx_off to
> > your kernel cmdline? If you can, try this both on mainline kernels
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/03/12 21:39, Daniel Vetter wrote:
> Yet another thing to try: Can you append intel_iommu=igfx_off to
> your kernel cmdline? If you can, try this both on mainline kernels
> and with my additional patches.
To confirm, intel_iommu=igfx_off is stabl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/03/12 21:39, Daniel Vetter wrote:
> Yet another thing to try: Can you append intel_iommu=igfx_off to
> your kernel cmdline? If you can, try this both on mainline kernels
> and with my additional patches.
To confirm, intel_iommu=igfx_off is stabl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/03/12 11:11, Tony Vroon wrote:
> No DMAR complaints in dmesg yet; it would have crashed by now if
> the fault was present.
To confirm, it is stable.
So ppgtt + VT-d is problematic on:
00:02.0 VGA compatible controller [0300]: Intel Corporation 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/03/12 11:01, Daniel Vetter wrote:
> Another thing for you to try is booting with
> i915.i915_enable_ppgtt=0 (and vt-d enabled of course).
That appears to be a winner:
adrastea ~ # uname -a
Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Tue M
On Tue, Mar 27, 2012 at 09:31:24PM +0200, Daniel Vetter wrote:
> On Mon, Mar 26, 2012 at 03:44:33PM +0100, Tony Vroon wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 26/03/12 15:32, Daniel Vetter wrote:
> > > Also, can you check whether disabling vt-d does work around the
>
On Mon, Mar 26, 2012 at 03:44:33PM +0100, Tony Vroon wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 26/03/12 15:32, Daniel Vetter wrote:
> > Also, can you check whether disabling vt-d does work around the
> > issue?
>
> Yes, that does appear to stay operational for longer on:
> L
On Tue, Mar 27, 2012 at 09:31:24PM +0200, Daniel Vetter wrote:
> On Mon, Mar 26, 2012 at 03:44:33PM +0100, Tony Vroon wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 26/03/12 15:32, Daniel Vetter wrote:
> > > Also, can you check whether disabling vt-d does work around the
>
On Mon, Mar 26, 2012 at 03:44:33PM +0100, Tony Vroon wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 26/03/12 15:32, Daniel Vetter wrote:
> > Also, can you check whether disabling vt-d does work around the
> > issue?
>
> Yes, that does appear to stay operational for longer on:
> L
On Mon, Mar 26, 2012 at 03:36:53PM +0100, Tony Vroon wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 26/03/12 15:32, Daniel Vetter wrote:
> > Ok, this is ugly. Do you have any special module options for i915
> > set (like i915_enable_rc6)?
>
> None set:
> adrastea ~ # cat /proc/cm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/03/12 11:11, Tony Vroon wrote:
> No DMAR complaints in dmesg yet; it would have crashed by now if
> the fault was present.
To confirm, it is stable.
So ppgtt + VT-d is problematic on:
00:02.0 VGA compatible controller [0300]: Intel Corporation 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/03/12 11:01, Daniel Vetter wrote:
> Another thing for you to try is booting with
> i915.i915_enable_ppgtt=0 (and vt-d enabled of course).
That appears to be a winner:
adrastea ~ # uname -a
Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Tue M
On Mon, Mar 26, 2012 at 03:36:53PM +0100, Tony Vroon wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 26/03/12 15:32, Daniel Vetter wrote:
> > Ok, this is ugly. Do you have any special module options for i915
> > set (like i915_enable_rc6)?
>
> None set:
> adrastea ~ # cat /proc/cm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 15:32, Daniel Vetter wrote:
> Also, can you check whether disabling vt-d does work around the
> issue?
Yes, that does appear to stay operational for longer on:
Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Mon Mar 26 11:29:21
BST 2012
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 15:32, Daniel Vetter wrote:
> Ok, this is ugly. Do you have any special module options for i915
> set (like i915_enable_rc6)?
None set:
adrastea ~ # cat /proc/cmdline
BOOT_IMAGE=3.3.0-04074-g53 rw root=0
> Also, can you check whether disa
On Mon, Mar 26, 2012 at 02:59:43PM +0100, Tony Vroon wrote:
> On 21/03/12 10:47, Dave Airlie wrote:
> > i915: re-enabling GMBUS, finish gpu patch (might help hibernation who
> > knows), missed irq fixes, stencil tiling fixes, interlaced support,
> > aliasesd PPGTT support for SNB/IVB, swizzling f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 15:32, Daniel Vetter wrote:
> Also, can you check whether disabling vt-d does work around the
> issue?
Yes, that does appear to stay operational for longer on:
Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Mon Mar 26 11:29:21
BST 2012
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/12 15:32, Daniel Vetter wrote:
> Ok, this is ugly. Do you have any special module options for i915
> set (like i915_enable_rc6)?
None set:
adrastea ~ # cat /proc/cmdline
BOOT_IMAGE=3.3.0-04074-g53 rw root=0
> Also, can you check whether disa
On 21/03/12 10:47, Dave Airlie wrote:
> i915: re-enabling GMBUS, finish gpu patch (might help hibernation who
> knows), missed irq fixes, stencil tiling fixes, interlaced support,
> aliasesd PPGTT support for SNB/IVB, swizzling for SNB/IVB, semaphore fixes
This causes an eventual (after barely a
On Mon, Mar 26, 2012 at 02:59:43PM +0100, Tony Vroon wrote:
> On 21/03/12 10:47, Dave Airlie wrote:
> > i915: re-enabling GMBUS, finish gpu patch (might help hibernation who
> > knows), missed irq fixes, stencil tiling fixes, interlaced support,
> > aliasesd PPGTT support for SNB/IVB, swizzling f
On Sat, Mar 24, 2012 at 12:15:27PM -0700, Linus Torvalds wrote:
> Btw, I think this came in through the DRM merge:
>
> ERROR: "mdfld_set_brightness" [drivers/gpu/drm/gma500/gma500_gfx.ko]
> undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> this is just "make AR
On Sat, Mar 24, 2012 at 12:15:27PM -0700, Linus Torvalds wrote:
> Btw, I think this came in through the DRM merge:
>
> ERROR: "mdfld_set_brightness" [drivers/gpu/drm/gma500/gma500_gfx.ko]
> undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> this is just "make AR
Btw, I think this came in through the DRM merge:
ERROR: "mdfld_set_brightness" [drivers/gpu/drm/gma500/gma500_gfx.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
this is just "make ARCH=i386" with allmodconfig.
Linus
On Wed, Mar 21, 2012
Btw, I think this came in through the DRM merge:
ERROR: "mdfld_set_brightness" [drivers/gpu/drm/gma500/gma500_gfx.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
this is just "make ARCH=i386" with allmodconfig.
Linus
On Wed, Mar 21, 2012
On Wed, Mar 21, 2012 at 3:47 AM, Dave Airlie wrote:
>
> (oh and any warnings you see in i915 are gcc's fault from what anyone can
> see).
Christ those are annoying. Has anybody contacted the gcc people about this?
Linus
___
dri-deve
On Wed, Mar 21, 2012 at 3:47 AM, Dave Airlie wrote:
>
> (oh and any warnings you see in i915 are gcc's fault from what anyone can
> see).
Christ those are annoying. Has anybody contacted the gcc people about this?
Linus
Hi Linus,
now mainline has a duplicated patch set for exynos drm driver so
please revert the patch below from mainline before merging with
drm-next to avoid conflict.
subject: drm exynos: use drm_fb_helper_set_par directly
commit id: 34418c25d64844625118b5eedc493f7904d77659
this patch had already
On Wed, Mar 21, 2012 at 5:31 PM, InKi Dae wrote:
> Hi Linus,
>
> now mainline has a duplicated patch set for exynos drm driver so
> please revert the patch below from mainline before merging with
> drm-next to avoid conflict.
> subject: drm exynos: use drm_fb_helper_set_par directly
> commit id: 3
On Wed, Mar 21, 2012 at 5:31 PM, InKi Dae wrote:
> Hi Linus,
>
> now mainline has a duplicated patch set for exynos drm driver so
> please revert the patch below from mainline before merging with
> drm-next to avoid conflict.
> subject: drm exynos: use drm_fb_helper_set_par directly
> commit id: 3
Hi Linus,
This is the main drm pull request, I'm probably going to send two more
smaller ones, will explain below.
This contains a patch that is also in the fbdev tree, but it should be the
same patch, it added an API for hot unplugging framebuffer devices, and I
need that API for a new drive
Hi Linus,
This is the main drm pull request, I'm probably going to send two more
smaller ones, will explain below.
This contains a patch that is also in the fbdev tree, but it should be the
same patch, it added an API for hot unplugging framebuffer devices, and I
need that API for a new drive
34 matches
Mail list logo