On Wed, Nov 23, 2011 at 02:25:14AM +0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang
> wrote:
>
> > So the v3 patch will behave equally well on KMS console, gnome desktop
> > and bare X. Shall we just use it, or go back and use the original
> > ->hot_remove patch?
>
> > Yes, VT-x and VT-d are both enabled from BIOS setup.
>
> Any reason for that? We've found all kinds of problems with DMAR enabled
> on these machines that is only resolved by completely turning it
> off. You might try with intel_iommu=off and make sure that's stable.
Well, there is reason for
Hi Linus,
Keith finally decloaked and sent me his -fixes queue so this is mostly
that along with some radeon i2c fixes/cleanups, a radeon fix for some
userspace problems and a couple of drm core and vga arb fixes.
I have some exynos changes I might send separatly to you, as that driver
only w
On Tue, 22 Nov 2011 19:44:52 -0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds
> wrote:
>
> > X is hung, but I can at least switch VT's and send this from a text
> > terminal..
>
> Yeah, the GPU is locked up; doesn't look like we did anything wrong in
> th
On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
>
> > So the user has to choose between 5W of power saving or having dmar? And
> > we default to giving them dmar? I think that's going to come as a
> > surprise to people
On Wed, Nov 23, 2011 at 2:23 AM, InKi Dae wrote:
> Hello, Dave.
>
> I had posted DRM Driver patchsets for Exsynos SoC but there is no any
> feedback. could you please review them? and if the patchsets have any
> problem, please give me your advice anytime. and also we are ready for
> next patchset
>
> I would like to bring to the attention of dri-devel and linux-fbdev
> community a set of hopefully useful and interesting patches that
> I (and a few other colleagues) have been working on during the past
> few months. Here, I will provide a short abstract, so that you can
> decide whether this
2011/11/23 Dave Airlie :
> On Wed, Nov 23, 2011 at 2:23 AM, InKi Dae wrote:
>> Hello, Dave.
>>
>> I had posted DRM Driver patchsets for Exsynos SoC but there is no any
>> feedback. could you please review them? and if the patchsets have any
>> problem, please give me your advice anytime. and also
On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
> >
> > > So the user has to choose between 5W of power saving or having dmar? And
> > > we default to giving th
On Wed, Nov 23, 2011 at 02:01:54PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> > On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett
> > > wrote:
> > >
> > > > So the user has to ch
On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> for the dmar+rc6 hangs reported.
Um... let me restate that for clarity (and partly for
On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> > At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> > dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> > for the dmar+rc6
On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
>
> Things I've tried that don't work around the issue:
> - Disable dmar for the igfx with intel_iommu=igfx_off
> - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
> idling while flushing).
Well, the ILK workaround was only
On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> > At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> > dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> > for the dmar+rc6
On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> Hm, that comment confuses me a bit. I've always thought that igfx_off only
> instantiates a identity mapping and leaves the dmar unit on. Is that
> wrong?
It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the on
On Wed, Nov 23, 2011 at 04:31:54PM +0100, Daniel Vetter wrote:
> - Wait 2 minutes for the stuck-in-atomic detection logic to kick in and
> grab the backtrace over netconsole. Notice that the kernel is stuck
> trying to flush the dmar tlb cache (that's how I managed to track it
> down to a dma
On 2011.11.21 at 16:36 +0100, Markus Trippelsdorf wrote:
> On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> > Le lundi 21 novembre 2011 à 14:15 +0100, Markus Trippelsdorf a écrit :
> >
> > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> > >
> >
> > Thanks
> >
> > Please conti
Those are needed by the rc6 and semaphores support in i915 driver.
In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. So we use those variables to check the io remapping and iommu
status.
CC: Keith Packard
CC: Daniel Vetter
Signed-off-by: Eugeni Dodonov
---
On Wed, 23 Nov 2011 16:29:58 +0800, Wu Fengguang wrote:
> What I need is a hot plug hook that knows whether the monitor is
> plugged or removed, which is only possible if the hook is called
> after ->detect().
That would be mode_set to tell you that the monitor is in use, and the
disable functio
On Wed, Nov 23, 2011 at 03:43:05PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> > Hm, that comment confuses me a bit. I've always thought that igfx_off only
> > instantiates a identity mapping and leaves the dmar unit on. Is that
> > wrong?
>
> It's co
On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
> Those are needed by the rc6 and semaphores support in i915 driver.
>
> In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
> is enabled. So we use those variables to check the io remapping and iommu
> status.
This i
On Wed, 23 Nov 2011 20:36:00 +, David Woodhouse wrote:
> This is horrid. In the general case, drivers have no business knowing
> this. We need to properly identify what is wrong with this hardware, and
> put in a quirk for it — perhaps refusing to enable the IOMMU at all on
> the broken chips
On Fri, 21 Oct 2011 09:10:12 +0200, Jean Delvare wrote:
> - /* vesa says 2.2 ms is enough, 1 jiffy doesn't seem to always
> - * make this, 2 jiffies is a lot more reliable */
> - i2c->algo.bit.timeout = 2;
> + i2c->algo.bit.timeout = usecs_to_jiffi
On Wed, 23 Nov 2011, Dave Airlie wrote:
So another question I have is how you would intend this to work from a
user POV, like how it would integrate with a desktop environment, X or
wayland, i.e. with little or no configuration.
First thing to understand is that when a virtual CRTC is creat
On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > FIX idr_layer_cache: Marking all objects used
>
> Yesterday I couldn't reproduce the issue at all. But today I've hit
> exactly the same spot again. (CCing the drm list)
Well this is looks like write after free.
> ==
> > > 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release
> > > hangs in random places while using X.
Also found out that 3.1-rc10 was already bad, will redo the bisect but
it takes days sinc I'm not at the machine most of the time.
> Do you have VT-d enabled in the BIOS?
Yes,
W dniu 21 listopada 2011 23:22 u?ytkownik Linus Torvalds
napisa?:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>>
>> Subject ? ?: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or
>> suspending
>> Submitter ?: Rafa? Mi?ecki
>> Date ? ? ? : 2011-11-09 11:46
>> Message-ID :
On Wed, Nov 23, 2011 at 02:25:14AM +0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang
> wrote:
>
> > So the v3 patch will behave equally well on KMS console, gnome desktop
> > and bare X. Shall we just use it, or go back and use the original
> > ->hot_remove patch?
>
> > Yes, VT-x and VT-d are both enabled from BIOS setup.
>
> Any reason for that? We've found all kinds of problems with DMAR enabled
> on these machines that is only resolved by completely turning it
> off. You might try with intel_iommu=off and make sure that's stable.
Well, there is reason for
Hi Linus,
Keith finally decloaked and sent me his -fixes queue so this is mostly
that along with some radeon i2c fixes/cleanups, a radeon fix for some
userspace problems and a couple of drm core and vga arb fixes.
I have some exynos changes I might send separatly to you, as that driver
only w
On Tue, 22 Nov 2011 19:44:52 -0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds linux-foundation.org> wrote:
>
> > X is hung, but I can at least switch VT's and send this from a text
> > terminal..
>
> Yeah, the GPU is locked up; doesn't look like we did any
On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
>
> > So the user has to choose between 5W of power saving or having dmar? And
> > we default to giving them dmar? I think that's going to come as a
> > surprise to people
On Wed, Nov 23, 2011 at 2:23 AM, InKi Dae wrote:
> Hello, Dave.
>
> I had posted DRM Driver patchsets for Exsynos SoC but there is no any
> feedback. could you please review them? and if the patchsets have any
> problem, please give me your advice anytime. and also we are ready for
> next patchset
>
> I would like to bring to the attention of dri-devel and linux-fbdev
> community a set of hopefully useful and interesting patches that
> I (and a few other colleagues) have been working on during the past
> few months. Here, I will provide a short abstract, so that you can
> decide whether this
2011/11/23 Dave Airlie :
> On Wed, Nov 23, 2011 at 2:23 AM, InKi Dae wrote:
>> Hello, Dave.
>>
>> I had posted DRM Driver patchsets for Exsynos SoC but there is no any
>> feedback. could you please review them? and if the patchsets have any
>> problem, please give me your advice anytime. and also
scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/86c5b9c5/attachment.bin>
On Wed, Nov 23, 2011 at 02:01:54PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> > On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett
> > > wrote:
> > >
> > > > So the user has to ch
ature
Size: 5818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/32652c1a/attachment-0001.bin>
On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> > At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> > dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> > for the dmar+rc6
;ll have
learned something :)
--
dwmw2
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/be93cddf/attachment.bin>
On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> > At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> > dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> > for the dmar+rc6
---
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/f271bad1/attachment-0001.bin>
On Wed, Nov 23, 2011 at 04:31:54PM +0100, Daniel Vetter wrote:
> - Wait 2 minutes for the stuck-in-atomic detection logic to kick in and
> grab the backtrace over netconsole. Notice that the kernel is stuck
> trying to flush the dmar tlb cache (that's how I managed to track it
> down to a dma
On 2011.11.21 at 16:36 +0100, Markus Trippelsdorf wrote:
> On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> > Le lundi 21 novembre 2011 ? 14:15 +0100, Markus Trippelsdorf a ?crit :
> >
> > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> > >
> >
> > Thanks
> >
> > Please conti
Those are needed by the rc6 and semaphores support in i915 driver.
In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. So we use those variables to check the io remapping and iommu
status.
CC: Keith Packard
CC: Daniel Vetter
Signed-off-by: Eugeni Dodonov
---
t attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/fdd0330f/attachment.pgp>
On Wed, Nov 23, 2011 at 03:43:05PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> > Hm, that comment confuses me a bit. I've always thought that igfx_off only
> > instantiates a identity mapping and leaves the dmar unit on. Is that
> > wrong?
>
> It's co
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/2a1941ae/attachment.bin>
ication/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/cba3939a/attachment.pgp>
On Fri, 21 Oct 2011 09:10:12 +0200, Jean Delvare wrote:
> - /* vesa says 2.2 ms is enough, 1 jiffy doesn't seem to always
> - * make this, 2 jiffies is a lot more reliable */
> - i2c->algo.bit.timeout = 2;
> + i2c->algo.bit.timeout = usecs_to_jiffi
On Wed, 23 Nov 2011, Dave Airlie wrote:
> So another question I have is how you would intend this to work from a
> user POV, like how it would integrate with a desktop environment, X or
> wayland, i.e. with little or no configuration.
>
First thing to understand is that when a virtual CRTC is c
On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > FIX idr_layer_cache: Marking all objects used
>
> Yesterday I couldn't reproduce the issue at all. But today I've hit
> exactly the same spot again. (CCing the drm list)
Well this is looks like write after free.
> ==
Mr. Park. I rebased the drm-fixes tree.
commit-id: 8f3f1c9a22a6420e28c2d3eff59b832893bc8efc
and you can find patches at git
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm
thank you.
2011/11/14 Kyungmin Park :
> Hi,
>
> Also you can find relevant patches at git
Hello, Dave.
I had posted DRM Driver patchsets for Exsynos SoC but there is no any
feedback. could you please review them? and if the patchsets have any
problem, please give me your advice anytime. and also we are ready for
next patchsets.
the next patchsets include the followings:
- fix some pre
There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips. The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.
Reported-by: Haogang Chen
Signed-off-by: Xi Wang
---
drivers/gpu/dr
55 matches
Mail list logo
