Dear Chris:
what do u mean " blit between snooped and unsnooped memory"?
It seems you want to map user-space pixmap to GTT space, and use 2d
copy to do upload/download?
TTM can map user space memory to GTT aperture by using
"ttm_bo_type_user", but no dirver use it yet.??
Thanks
2011/1/8 Chris
https://bugzilla.kernel.org/show_bug.cgi?id=26552
Rafael J. Wysocki changed:
What|Removed |Added
CC||florian at mickler.org,
https://bugzilla.kernel.org/show_bug.cgi?id=26552
--- Comment #1 from Andrea Iob 2011-01-11 22:54:49 ---
Created an attachment (id=43292)
--> (https://bugzilla.kernel.org/attachment.cgi?id=43292)
dmesg when there is no flickering
--
Configure bugmail: https://bugzilla.kernel.org/userprefs
https://bugzilla.kernel.org/show_bug.cgi?id=26552
Summary: Screen flickering with 2.6.37 [ATI X1600]
Product: Drivers
Version: 2.5
Kernel Version: 2.6.37
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=33011
--- Comment #1 from Alex Deucher 2011-01-11 22:38:09 PST ---
Please attach your xorg log and dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=33011
--- Comment #1 from Alex Deucher 2011-01-11 22:38:09 PST
---
Please attach your xorg log and dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
On Tue, 11 Jan 2011 14:16:54 -0800, Linus Torvalds wrote:
> The BUG_ON() that triggers is appended. And as mentioned, the jerky
> thing really seems to start happening in the exact same circumstance
> when this BUG_ON triggered.
Yes, that is the race in IRQ refcounting that I have an outstanding
https://bugs.freedesktop.org/show_bug.cgi?id=33011
Summary: HDMI-A-1 Does not work if disconnected at power-up
(But claims it does)
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=33011
Summary: HDMI-A-1 Does not work if disconnected at power-up
(But claims it does)
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
I'm stuck at home with just my i5 laptop due to the office being shut due
to the ongoing floods. But I've booted and ran this for a few hours and it
seems to be better than the current tree. It contains a couple of patches
to fix DMAR interaction issues I see on this laptop on top of Chris's
pu
On Tue, 11 Jan 2011 11:45:05 -0800, Jesse Barnes
wrote:
> On Tue, 11 Jan 2011 11:25:39 -0800
> Linus Torvalds wrote:
>
> > On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes > virtuousgeek.org> wrote:
> > >
> > > Have you tried reproducing it using xset dpms force off or similar?
> >
> > That doe
Dave, in the future, can you make pull requests like Ingo ?
What I mean:
non-drm
generic
power
nouveau
radeon
intel
others
On Tue 11-01-11 18:37:41, Michal Hocko wrote:
> On Tue 11-01-11 18:17:44, Michal Hocko wrote:
> > [Let's CC Indan - author of the bugzilla patches]
> >
> > On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> > > Hi,
> > >
> > > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > > [...]
> > > > We di
On Tue 11-01-11 17:39:42, Chris Wilson wrote:
> On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote:
> > [Let's CC Indan - author of the bugzilla patches]
> >
> > On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> > > Hi,
> > >
> > > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > > [...]
>
On Tue 11-01-11 18:17:44, Michal Hocko wrote:
> [Let's CC Indan - author of the bugzilla patches]
>
> On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> > Hi,
> >
> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > [...]
> > > We did have another revert to fix hopefullythe last "blank screen"
>
On Tue, Jan 11, 2011 at 6:11 PM, Anca Emanuel wrote:
> Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
> until is more stable ?
What I have done:
git bisect log
git bisect start
# bad: [5b2eef966cb2ae307aa4ef1767f7307774bc96ca] Merge branch
'drm-core-next' of
git://git.kernel.or
[Let's CC Indan - author of the bugzilla patches]
On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> Hi,
>
> On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> [...]
> > We did have another revert to fix hopefullythe last "blank screen"
> > regression on intel graphics.
>
> It seems that there is st
On Tue, Jan 11, 2011 at 6:01 PM, Linus Torvalds
wrote:
> On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes
> wrote:
>>
>> Arg. ?It's been ok on my ILK systems, but Chris has found some issues with
>> out watermarking code iirc; apparently we're underflowing the display FIFO,
>> causing all sorts
Use the common one for all asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 27 +--
drivers/gpu/drm/radeon/r600.c | 20 +---
drivers/gpu/drm/radeon/rv770.c |2 +-
3 files changed, 3 insertions(+), 46 deletions(-)
On Wed, Jan 12, 2011 at 11:36 AM, Linus Torvalds
wrote:
> On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
> wrote:
>>
>> ... I'll test that drm-intel-staging commit.
>
> Initial testing _seems_ to confirm that merging drm-intel-staging gets
> rid of the problem. But I haven't spent a whole lot o
https://bugs.freedesktop.org/show_bug.cgi?id=24414
Ian Romanick changed:
What|Removed |Added
Keywords||NEEDINFO
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=24414
Ian Romanick changed:
What|Removed |Added
Keywords||NEEDINFO
CC|
On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote:
> [Let's CC Indan - author of the bugzilla patches]
>
> On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> > Hi,
> >
> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > [...]
> > > We did have another revert to fix hopefullythe last "blank
On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
wrote:
>
> ... I'll test that drm-intel-staging commit.
Initial testing _seems_ to confirm that merging drm-intel-staging gets
rid of the problem. But I haven't spent a whole lot of time in the
screen saver. Will start driving kids around now, so m
On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
wrote:
>
> ... I'll test that drm-intel-staging commit.
Initial testing _seems_ to confirm that merging drm-intel-staging gets
rid of the problem. But I haven't spent a whole lot of time in the
screen saver. Will start driving kids around now, so m
Hello,
On Tue, January 11, 2011 18:39, Chris Wilson wrote:
> On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote:
>> [Let's CC Indan - author of the bugzilla patches]
>>
>> On Thu 06-01-11 11:48:16, Michal Hocko wrote:
>> > Hi,
>> >
>> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
>> > [..
On Tue, Jan 11, 2011 at 4:28 PM, Dave Airlie wrote:
> On Tue, Jan 11, 2011 at 4:06 PM, Jesse Barnes
> wrote:
>> "Dave Airlie" wrote:
>>
>>>On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
>>> wrote:
On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie
>>>wrote:
> Highlights:
> core/drivers
On Mon, Jan 10, 2011 at 8:24 PM, Konrad Rzeszutek Wilk
wrote:
>> AMD chipset.
>
> They don't seem to have have any errata's for this GFX business.
> But they do have a passthrough mode - hopefull that is not what you have
> passed in?
>
>> > Since you mentioned that you were able to passthrough ot
On Tue, Jan 11, 2011 at 4:06 PM, Jesse Barnes
wrote:
> "Dave Airlie" wrote:
>
>>On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
>> wrote:
>>> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie
>>wrote:
Highlights:
core/drivers: add support for high precision vblank timestamps
radeon: p
Am 10.01.2011 23:59, schrieb Dave Airlie:
>
> Hi Linus,
>
> non-drm changes:
> one kref change we needed that went on list with no comments
>
> New hardware:
> radeon: add support for Fusion APUs and Radeon HD6xxx chipsets
> nouveau: Fermi acceleration support (requires external fw for now)
>
>
On Tue, Jan 11, 2011 at 14:33, Pavel Machek wrote:
>> I can reproduce the problem easily by:
>> xset dpms force standby; sleep 3s; xset dpms force on
>
> (You are using "vesa" or "fbcon" X11 driver, right? I seen same problem
> until I switched to "intel" X11 driver).
No, the "intel".
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
wrote:
>
> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA
> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
> During startup the framebuffer shows only stripes and a blank
> screen after suspend
On Tue 11-01-11 14:33:20, Pavel Machek wrote:
> > Hi,
> >
> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > [...]
> > > We did have another revert to fix hopefullythe last "blank screen"
> > > regression on intel graphics.
> >
> > It seems that there is still a regression for intel graphic
On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
wrote:
>
> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA
> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
> During startup the framebuffer shows only stripes and a blank
> screen after suspend
is the 8GB->24GB, but it still has 4GB->8GB free - so it can launch one more
guest (but without PCI passthrough devices).
> On a 4GB machine or less, that would be the same as kernel memory.
> Now, if 4 guests think they can allocate 2GB of coherent memory
> each, you might run out of kernel memor
https://bugzilla.kernel.org/show_bug.cgi?id=26552
Rafael J. Wysocki changed:
What|Removed |Added
CC||flor...@mickler.org,
Use the common one for all asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 27 +--
drivers/gpu/drm/radeon/r600.c | 20 +---
drivers/gpu/drm/radeon/rv770.c |2 +-
3 files changed, 3 insertions(+), 46 deletions(-)
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
wrote:
>
> I'll test the merge, but I thought I'd send out this note already at
> this point, because I'm pretty sure this is it.
Hmm. The merge already has the *ERROR* Hangcheck (together with jerky
behavior), so it wasn't actually the polling patc
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
wrote:
>
> I'll test the merge, but I thought I'd send out this note already at
> this point, because I'm pretty sure this is it.
Hmm. The merge already has the *ERROR* Hangcheck (together with jerky
behavior), so it wasn't actually the polling patc
https://bugzilla.kernel.org/show_bug.cgi?id=26552
--- Comment #1 from Andrea Iob 2011-01-11 22:54:49 ---
Created an attachment (id=43292)
--> (https://bugzilla.kernel.org/attachment.cgi?id=43292)
dmesg when there is no flickering
--
Configure bugmail: https://bugzilla.kernel.org/userprefs
https://bugzilla.kernel.org/show_bug.cgi?id=26552
Summary: Screen flickering with 2.6.37 [ATI X1600]
Product: Drivers
Version: 2.5
Kernel Version: 2.6.37
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie wrote:
> On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
> wrote:
>> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie wrote:
>>> Highlights:
>>> core/drivers: add support for high precision vblank timestamps
>>> radeon: pageflipping support, Gen2 PCIE sup
On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
wrote:
> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie wrote:
>> Highlights:
>> core/drivers: add support for high precision vblank timestamps
>> radeon: pageflipping support, Gen2 PCIE support
>> nouveau: reworked VRAM and VM support
>> intel: bette
Hi!
> >>> Highlights:
> >>> core/drivers: add support for high precision vblank timestamps
> >>> radeon: pageflipping support, Gen2 PCIE support
> >>> nouveau: reworked VRAM and VM support
> >>> intel: better ILK/SNB powersaving support, Full GTT support
> >>
> >> Lowlights: it's broken.
Heh, at
> Hi,
>
> On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> [...]
> > We did have another revert to fix hopefullythe last "blank screen"
> > regression on intel graphics.
>
> It seems that there is still a regression for intel graphic cards
> backlight. One report is https://bugzilla.kernel.org/s
On Tue, 11 Jan 2011 14:16:54 -0800, Linus Torvalds
wrote:
> The BUG_ON() that triggers is appended. And as mentioned, the jerky
> thing really seems to start happening in the exact same circumstance
> when this BUG_ON triggered.
Yes, that is the race in IRQ refcounting that I have an outstanding
On Tue, Jan 11, 2011 at 1:28 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
>> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
>> wrote:
>> >> >> Another thing that I was thinking of is what happens if you have a
>> >> >> huge gart and all
On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
wrote:
>
> Maybe the screen just has to be inactive for a longer time: do you do
> some dynamic "let's power things down if nothing is changing"?
So since this is _almost_ reproducible for me, I tried bisecting it.
The bisection is a bit iffy, sin
On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
wrote:
>
> Maybe the screen just has to be inactive for a longer time: do you do
> some dynamic "let's power things down if nothing is changing"?
So since this is _almost_ reproducible for me, I tried bisecting it.
The bisection is a bit iffy, sin
On Tue, 11 Jan 2011 14:33:29 +0100, Pavel Machek wrote:
> Hi!
>
> > >>> Highlights:
> > >>> core/drivers: add support for high precision vblank timestamps
> > >>> radeon: pageflipping support, Gen2 PCIE support
> > >>> nouveau: reworked VRAM and VM support
> > >>> intel: better ILK/SNB powersavin
First, we were calling mc_stop() at the top of the function
which turns off all MC (memory controller) clients,
then checking if the GPU is idle. If it was idle we
returned without re-enabling the MC clients which would
lead to a blank screen, etc. This patch checks if the
GPU is idle before call
On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
> wrote:
> >> >> Another thing that I was thinking of is what happens if you have a
> >> >> huge gart and allocate a lot of coherent memory. Could that
> >> >> potentially exhaus
> > What motherboard is this?
>
> ASUS M4A89TD Pro/USB3, it is mentioned on the link
> http://wiki.xensource.com/xenwiki/VTdHowTo
I am not sure how the implementation of the IOMMU
in the Xen hypervisor is different from the Linux implementation.
Usually it is lock-step, but it might be different.
On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
wrote:
>> >> Another thing that I was thinking of is what happens if you have a
>> >> huge gart and allocate a lot of coherent memory. Could that
>> >> potentially exhaust IOMMU resources?
>> >
>> >
>> >
>> > So the GART is in the PCI space
dri-devel/attachments/20110111/3a2dc40e/attachment-0001.jpeg>
On Tue, Jan 11, 2011 at 11:58 AM, Prasad Joshi
wrote:
> On Mon, Jan 10, 2011 at 8:24 PM, Konrad Rzeszutek Wilk
> wrote:
>>> AMD chipset.
>>
>> They don't seem to have have any errata's for this GFX business.
>> But they do have a passthrough mode - hopefull that is not what you have
>> passed in
On Tue, 11 Jan 2011 11:45:05 -0800, Jesse Barnes
wrote:
> On Tue, 11 Jan 2011 11:25:39 -0800
> Linus Torvalds wrote:
>
> > On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes
> > wrote:
> > >
> > > Have you tried reproducing it using xset dpms force off or similar?
> >
> > That doesn't seem to do
> >> Another thing that I was thinking of is what happens if you have a
> >> huge gart and allocate a lot of coherent memory. Could that
> >> potentially exhaust IOMMU resources?
> >
> >
> >
> > So the GART is in the PCI space in one of the BARs of the device right?
> > (We are talking about the d
On Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes wrote:
>>
>> Maybe the screen just has to be inactive for a longer time: do you do
>> some dynamic "let's power things down if nothing is changing"?
>
> There are some timeouts, the FBC engine will recompress about once
> every 15s; the self-refresh t
On Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes
wrote:
>>
>> Maybe the screen just has to be inactive for a longer time: do you do
>> some dynamic "let's power things down if nothing is changing"?
>
> There are some timeouts, the FBC engine will recompress about once
> every 15s; the self-refresh
On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes
> wrote:
> >
> > Have you tried reproducing it using xset dpms force off or similar?
>
> That doesn't seem to do anything bad.
>
> In fact, I think the second time it happened the screen
On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes
> wrote:
> >
> > Have you tried reproducing it using xset dpms force off or similar?
>
> That doesn't seem to do anything bad.
>
> In fact, I think the second time it happened the screen
On Tue, Jan 11, 2011 at 1:28 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
>> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
>> wrote:
>> >> >> Another thing that I was thinking of is what happens if you have a
>> >> >> huge gart and all
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes wrote:
>
> Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I think the second time it happened the screen never went
black - just the random photo thing was on. But no, forcing the s
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes
wrote:
>
> Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I think the second time it happened the screen never went
black - just the random photo thing was on. But no, forcing the
On Tue, Jan 11, 2011 at 10:55 AM, Konrad Rzeszutek Wilk
wrote:
> . snip ..
>> >>>I think the error path would be the same in both cases?
>> >>Not really. The really dangerous situation is if TTM is allowed to
>> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
>> >Ok, since GFP
On Tue, 11 Jan 2011 11:00:13 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
> wrote:
> >
> > But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> > this message on this machine before.
>
> .. and it's not a fluke. It happened again, and once more w
On Tue, 11 Jan 2011 11:00:13 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
> wrote:
> >
> > But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> > this message on this machine before.
>
> .. and it's not a fluke. It happened again, and once more w
On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
wrote:
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
.. and it's not a fluke. It happened again, and once more while I was
away from the machine and the screen saver was running. So it
On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
wrote:
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
.. and it's not a fluke. It happened again, and once more while I was
away from the machine and the screen saver was running. So it
On Tue, 11 Jan 2011 14:51:40 +1000, Dave Airlie wrote:
> On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie wrote:
> > On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
> > wrote:
> >> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie wrote:
> >>> Highlights:
> >>> core/drivers: add support for high precisi
. snip ..
> >>>I think the error path would be the same in both cases?
> >>Not really. The really dangerous situation is if TTM is allowed to
> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
> >Ok, since GFP_KERNEL does not contain the GFP_DMA32 flag then
> >this should be OK?
From: Michel D?nzer
I'm amazed but not really surprised this worked on x86...
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_irq_kms.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/ra
On Tue 11-01-11 18:37:41, Michal Hocko wrote:
> On Tue 11-01-11 18:17:44, Michal Hocko wrote:
> > [Let's CC Indan - author of the bugzilla patches]
> >
> > On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> > > Hi,
> > >
> > > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > > [...]
> > > > We di
First, we were calling mc_stop() at the top of the function
which turns off all MC (memory controller) clients,
then checking if the GPU is idle. If it was idle we
returned without re-enabling the MC clients which would
lead to a blank screen, etc. This patch checks if the
GPU is idle before call
On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
> wrote:
> >> >> Another thing that I was thinking of is what happens if you have a
> >> >> huge gart and allocate a lot of coherent memory. Could that
> >> >> potentially exhaus
> > What motherboard is this?
>
> ASUS M4A89TD Pro/USB3, it is mentioned on the link
> http://wiki.xensource.com/xenwiki/VTdHowTo
I am not sure how the implementation of the IOMMU
in the Xen hypervisor is different from the Linux implementation.
Usually it is lock-step, but it might be different.
On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
wrote:
>> >> Another thing that I was thinking of is what happens if you have a
>> >> huge gart and allocate a lot of coherent memory. Could that
>> >> potentially exhaust IOMMU resources?
>> >
>> >
>> >
>> > So the GART is in the PCI space
https://bugs.freedesktop.org/show_bug.cgi?id=32918
--- Comment #7 from Lee Wilson 2011-01-11 10:12:53 PST
---
I just checked it and yeah, its clutter built from git
** Checking out clutter *** [13/33]
git clone git://git.clutter-project.org/clutter
Initialized
--
Configure bugmail: https:/
https://bugs.freedesktop.org/show_bug.cgi?id=32918
--- Comment #7 from Lee Wilson 2011-01-11 10:12:53
PST ---
I just checked it and yeah, its clutter built from git
** Checking out clutter *** [13/33]
git clone git://git.clutter-project.org/clutter
Initialized
--
Configure bugmail: https:/
Dave, in the future, can you make pull requests like Ingo ?
What I mean:
non-drm
generic
power
nouveau
radeon
intel
others
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue 11-01-11 17:39:42, Chris Wilson wrote:
> On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote:
> > [Let's CC Indan - author of the bugzilla patches]
> >
> > On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> > > Hi,
> > >
> > > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > > [...]
>
On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko wrote:
> [Let's CC Indan - author of the bugzilla patches]
>
> On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> > Hi,
> >
> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > [...]
> > > We did have another revert to fix hopefullythe last "blank
On Tue 11-01-11 18:17:44, Michal Hocko wrote:
> [Let's CC Indan - author of the bugzilla patches]
>
> On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> > Hi,
> >
> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > [...]
> > > We did have another revert to fix hopefullythe last "blank screen"
>
[Let's CC Indan - author of the bugzilla patches]
On Thu 06-01-11 11:48:16, Michal Hocko wrote:
> Hi,
>
> On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> [...]
> > We did have another revert to fix hopefullythe last "blank screen"
> > regression on intel graphics.
>
> It seems that there is st
On Tue, Jan 11, 2011 at 6:11 PM, Anca Emanuel wrote:
> Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
> until is more stable ?
What I have done:
git bisect log
git bisect start
# bad: [5b2eef966cb2ae307aa4ef1767f7307774bc96ca] Merge branch
'drm-core-next' of
git://git.kernel.or
On Tue, Jan 11, 2011 at 6:01 PM, Linus Torvalds
wrote:
> On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes
> wrote:
>>
>> Arg. It's been ok on my ILK systems, but Chris has found some issues with
>> out watermarking code iirc; apparently we're underflowing the display FIFO,
>> causing all sorts
On Tue, Jan 11, 2011 at 11:58 AM, Prasad Joshi wrote:
> On Mon, Jan 10, 2011 at 8:24 PM, Konrad Rzeszutek Wilk
> wrote:
>>> AMD chipset.
>>
>> They don't seem to have have any errata's for this GFX business.
>> But they do have a passthrough mode - hopefull that is not what you have
>> passed in?
> >> Another thing that I was thinking of is what happens if you have a
> >> huge gart and allocate a lot of coherent memory. Could that
> >> potentially exhaust IOMMU resources?
> >
> >
> >
> > So the GART is in the PCI space in one of the BARs of the device right?
> > (We are talking about the d
On Mon, Jan 10, 2011 at 8:24 PM, Konrad Rzeszutek Wilk
wrote:
>> AMD chipset.
>
> They don't seem to have have any errata's for this GFX business.
> But they do have a passthrough mode - hopefull that is not what you have
> passed in?
>
>> > Since you mentioned that you were able to passthrough ot
On Tue, Jan 11, 2011 at 10:55 AM, Konrad Rzeszutek Wilk
wrote:
> . snip ..
>> >>>I think the error path would be the same in both cases?
>> >>Not really. The really dangerous situation is if TTM is allowed to
>> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
>> >Ok, since GFP
https://bugs.freedesktop.org/show_bug.cgi?id=17819
--- Comment #3 from Thierry Vignaud 2011-01-11
08:20:18 PST ---
Looks somewhat like Bug #32871 which I'm seeing for quite a lot of time (maybe
since 2008 at least)
Bug #32871 show image comparaisons, provides the user case that seems to cause
th
https://bugs.freedesktop.org/show_bug.cgi?id=17819
--- Comment #3 from Thierry Vignaud 2011-01-11
08:20:18 PST ---
Looks somewhat like Bug #32871 which I'm seeing for quite a lot of time (maybe
since 2008 at least)
Bug #32871 show image comparaisons, provides the user case that seems to cause
th
On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes wrote:
>
> Arg. It's been ok on my ILK systems, but Chris has found some issues with
> out watermarking code iirc; apparently we're underflowing the display FIFO,
> causing all sorts of trouble. If it works before the pull of Dave's tree,
> can y
On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes
wrote:
>
> Arg. ?It's been ok on my ILK systems, but Chris has found some issues with
> out watermarking code iirc; apparently we're underflowing the display FIFO,
> causing all sorts of trouble. ?If it works before the pull of Dave's tree,
> can
. snip ..
> >>>I think the error path would be the same in both cases?
> >>Not really. The really dangerous situation is if TTM is allowed to
> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
> >Ok, since GFP_KERNEL does not contain the GFP_DMA32 flag then
> >this should be OK?
On Tue, Jan 11, 2011 at 14:33, Pavel Machek wrote:
>> I can reproduce the problem easily by:
>> xset dpms force standby; sleep 3s; xset dpms force on
>
> (You are using "vesa" or "fbcon" X11 driver, right? I seen same problem
> until I switched to "intel" X11 driver).
No, the "intel".
___
On Tue 11-01-11 14:33:20, Pavel Machek wrote:
> > Hi,
> >
> > On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> > [...]
> > > We did have another revert to fix hopefullythe last "blank screen"
> > > regression on intel graphics.
> >
> > It seems that there is still a regression for intel graphic
On Tue, 11 Jan 2011 14:33:29 +0100, Pavel Machek wrote:
> Hi!
>
> > >>> Highlights:
> > >>> core/drivers: add support for high precision vblank timestamps
> > >>> radeon: pageflipping support, Gen2 PCIE support
> > >>> nouveau: reworked VRAM and VM support
> > >>> intel: better ILK/SNB powersavin
> Hi,
>
> On Tue 04-01-11 17:15:45, Linus Torvalds wrote:
> [...]
> > We did have another revert to fix hopefullythe last "blank screen"
> > regression on intel graphics.
>
> It seems that there is still a regression for intel graphic cards
> backlight. One report is https://bugzilla.kernel.org/s
1 - 100 of 103 matches
Mail list logo
