[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=26552


Rafael J. Wysocki  changed:

   What|Removed |Added

 CC||florian at mickler.org,
   ||maciej.rutecki at gmail.com,
   ||rjw at sisk.pl
 Blocks||21782




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]

[bugzilla-dae...@bugzilla.kernel.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.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 26552] New: Screen flickering with 2.6.37 [ATI X1600]

[bugzilla-dae...@bugzilla.kernel.org]

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
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: andrea_iob at yahoo.it
Regression: Yes


Created an attachment (id=43282)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=43282)
dmesg when flickering is present

Starting from 2.6.37 the screen on my Toshiba Satellite A100 flickers as soon
as kernel modesetting is initialized. The flickering does not occur always:
sometimes the screen is almost unreadable, sometimes there is no flickering at
all.

With 2.6.36 (and previous versions) I've never experienced flickering problems.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 33011] HDMI-A-1 Does not work if disconnected at power-up (But claims it does)

[bugzilla-dae...@freedesktop.org]

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 the assignee for the bug.

[git pull] drm for rc1

[Chris Wilson]

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 fix
for.

I've put the patches up on drm-intel-staging as I begin retesting them
before sending the pull request. In particular you need
01a03331e5fe91861937f8b8e72c259f5e9eae67.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 33011] New: HDMI-A-1 Does not work if disconnected at power-up (But claims it does)

[bugzilla-dae...@freedesktop.org]

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)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: Russ.Dill at gmail.com


I have an "ATI Mobility Radeon X1600" (ChipID = 0x71c5). It has four outputs,
VGA-1, LVDS-1, HDMI-A-1, and SVIDEO-1.

I'm running 2.6.37 final (Ubuntu 2.6.37-12.26) and the Ubuntu xorg edgers
1:6.13.99+git20110110.0e432dff-0ubuntu0sarvatt version of
xserver-xorg-video-ati. I'm pretty sure this has something to do with a display
being plugged into VGA-1 as well.

xrandr --prop
Screen 0: minimum 320 x 200, current 3840 x 1350, maximum 8192 x 8192
VGA-0 connected 1920x1200+0+150 (normal left inverted right x axis y axis)
550mm x 340mm
EDID:
00000469a42664070200
1e140103683722782acbd0a35a49a024
135054bfef00714f0101814081809500
b300d1c00101283c80a070b023403020
36002654211a00ff0041374c
4d54463133323936340a00fd0032
4b1e5511000a20202020202000fc
0041535553205657323636480a200054
load detection: 1 (0x0001)range:  (0,1)
   1920x1200  60.0*+
   1920x1080  60.0  
   1680x1050  60.0  
   1280x1024  75.0 60.0  
   1440x900   59.9  
   1280x960   60.0  
   1152x864   75.0  
   1024x768   75.1 70.1 60.0  
   832x62474.6  
   800x60072.2 75.0 60.3 56.2  
   640x48072.8 75.0 66.7 60.0  
   720x40070.1  
LVDS connected (normal left inverted right x axis y axis)
EDID:
00004ca34635
00100103802115780a87f594574f8c27
2750540001010101010101010101
010101010101442f90c4601a0f401858
13004bcf1019000f
003cd20264fe0053
414d53554e470a202020202000fe
004c544e31353450342d4c30310a007f
scaling mode:Full
supported: None Full Center   Full aspect 
   1680x1050  60.6 +
   1400x1050  60.0  
   1280x1024  59.9  
   1440x900   59.9  
   1280x960   59.9  
   1280x854   59.9  
   1280x800   59.8  
   1280x720   59.9  
   1152x768   59.8  
   1024x768   59.9  
   800x60059.9  
   848x48059.7  
   720x48059.7  
   640x48059.4  
S-video disconnected (normal left inverted right x axis y axis)
tv standard:ntsc
supported: ntsc pal  pal-mpal-60  
   ntsc-j   scart-palpal-cn   secam   
load detection: 1 (0x0001)range:  (0,1)
HDMI-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis)
550mm x 340mm
EDID:
00000469a42660070200
1e140103803722782acbd0a35a49a024
135054bfef00714f0101814081809500
b30001010101283c80a070b023403020
36002654211a00ff0041374c
4d54463133323936300a00fd0032
4b1e5511000a20202020202000fc
0041535553205657323636480a2000d3
underscan vborder: 0 (0x)range:  (0,128)
underscan hborder: 0 (0x)range:  (0,128)
underscan:auto
supported: off  on   auto
coherent: 1 (0x0001)range:  (0,1)
   1920x1200  60.0*+
   1680x1050  60.0  
   1280x1024  75.0 60.0  
   1440x900   59.9  
   1280x960   60.0  
   1152x864   75.0  
   1024x768   75.1 70.1 60.0  
   832x62474.6  
   800x60072.2 75.0 60.3 56.2  
   640x48072.8 75.0 66.7 60.0  
   720x40070.1  


When I plug my laptop into the docking station which the monitor is plugged
into, I get:

[ 94924.709] (II) RADEON(0): EDID vendor "SEC", prod id 13638
[ 94924.709] (II) RADEON(0): Printing DDC gathered Modelines:
[ 94924.709] (II) RADEON(0): Modeline "1680x1050"x0.0  121.00  1680 1704 1792
1876  1050 1051 1054 1065 -hsync -vsync (64.5 kHz)
[ 94926.272] (II) RADEON(0): EDID vendor "SEC", prod id 13638
[ 94926.272] (II) RADEON(0): Printing DDC gathered Modelines:
[ 94926.272] (II) RADEON(0): Modeline "1680x1050"x0.0  121.00  1680 1704 1792
1876  1050 1051 1054 1065 -hsync -vsync (64.5 kHz)
[ 94926.537] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840
[ 94926.749] (II) RADEON(0): VRAM usage limit set to 213120K

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[git pull] drm for rc1

[Chris Wilson]

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 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 screen
> > saver on doesn't do it either (ie pressing the "lock screen" icon and
> > waiting for a few pictures to cycle).
> > 
> > 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 timers are much smaller though so it should
> be active anytime the CPU enters a deep sleep state.  The clock
> frequency changes in millisecond time too, you can check the status of
> that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.
> 
> I wonder if re-enabling rc6 may have caused your issues?  That would be:
> 
> commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
> Author: Jesse Barnes 
> Date:   Wed Jan 5 12:01:24 2011 -0800
> 
> drm/i915: re-enable rc6 support for Ironlake+

We haven't actually got as far as that patch yet, that's waiting for a
suitable juncture to send the request. Now that the trees have converged I
can pick which patches need to go for rc1 and which can wait for -next.

Looking at the set of outstanding patch, my suspect would be the ring irq
refcounting which needed a fix and seems implicated by the error message.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] drm for rc1

[Anca Emanuel]

Dave, in the future, can you make pull requests like Ingo ?
What I mean:
non-drm
generic
power
nouveau
radeon
intel
others

Linux 2.6.37

[Michal Hocko]

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 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/show_bug.cgi?id=22672.
> > > I can reproduce the problem easily by:
> > > xset dpms force standby; sleep 3s; xset dpms force on
> > > 
> > > backlight doesn't get up (there is really dark picture though which
> > > doesn't get brighter by function keys which work normally) after dpms on
> > > until I close and open lid. 
> > > 
> > > The problem wasn't present in 2.6.36
> > 
> > I can confirm that this problem is not present if both patches from
> > bko#22672 are applied on top of 2.6.37 kernel.
> > I haven't tried both patches separately, but I can surely try it if it
> > makes any sense.
> 
> I have just tried that and they are really both necessary.

I must have mixed something. After retesting with the first patch
(https://bugzilla.kernel.org/show_bug.cgi?id=22672#c33) the usecase
works just fine (backlight is on without need to close the lid)

Sorry for confusion

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic

Linux 2.6.37

[Michal Hocko]

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:
> > > [...]
> > > > 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/show_bug.cgi?id=22672.
> > > I can reproduce the problem easily by:
> > > xset dpms force standby; sleep 3s; xset dpms force on
> > > 
> > > backlight doesn't get up (there is really dark picture though which
> > > doesn't get brighter by function keys which work normally) after dpms on
> > > until I close and open lid. 
> > > 
> > > The problem wasn't present in 2.6.36
> > 
> > I can confirm that this problem is not present if both patches from
> > bko#22672 are applied on top of 2.6.37 kernel.
> > I haven't tried both patches separately, but I can surely try it if it
> > makes any sense.
> 
> The second patch is wrong in that it will prevent changing resolutions
> using the panel fitter. The first patch looks along the right lines, just
> misses the possibility that the backlight can be modified by other means.
> 
> So hopefully, you just need the first patch.

I would have bet I have tested the 1st patch but let me double check.
The 2nd patch alone doesn't fix the problem.

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic

Linux 2.6.37

[Michal Hocko]

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"
> > > regression on intel graphics.
> > 
> > It seems that there is still a regression for intel graphic cards
> > backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
> > I can reproduce the problem easily by:
> > xset dpms force standby; sleep 3s; xset dpms force on
> > 
> > backlight doesn't get up (there is really dark picture though which
> > doesn't get brighter by function keys which work normally) after dpms on
> > until I close and open lid. 
> > 
> > The problem wasn't present in 2.6.36
> 
> I can confirm that this problem is not present if both patches from
> bko#22672 are applied on top of 2.6.37 kernel.
> I haven't tried both patches separately, but I can surely try it if it
> makes any sense.

I have just tried that and they are really both necessary.


-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic

[git pull] drm for rc1

[Anca Emanuel]

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.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect bad 5b2eef966cb2ae307aa4ef1767f7307774bc96ca
# good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37
git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5
# good: [c413521eb4e2d7ffd5ce432a144708d479054bd3] ARM: mach-shmobile:
update for SMP changes.
git bisect good c413521eb4e2d7ffd5ce432a144708d479054bd3
# bad: [78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252] Merge branch
'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect bad 78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252
# bad: [da40d036fd716f0efb2917076220814b1e927ae1] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git bisect bad da40d036fd716f0efb2917076220814b1e927ae1
# bad: [dc69d1af9e8d9cbbabff88bb35a6782187a9] omap2: Make
OMAP2PLUS select OMAP_DM_TIMER
git bisect bad dc69d1af9e8d9cbbabff88bb35a6782187a9

Second bisect bad: nouveau not loaded, but I have an usable system.
I don't feel I'm doing it right.

Linux 2.6.37

[Michal Hocko]

[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 still a regression for intel graphic cards
> backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
> I can reproduce the problem easily by:
> xset dpms force standby; sleep 3s; xset dpms force on
> 
> backlight doesn't get up (there is really dark picture though which
> doesn't get brighter by function keys which work normally) after dpms on
> until I close and open lid. 
> 
> The problem wasn't present in 2.6.36

I can confirm that this problem is not present if both patches from
bko#22672 are applied on top of 2.6.37 kernel.
I haven't tried both patches separately, but I can surely try it if it
makes any sense.

> 
> $ lspci -vv
> [...]
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
> 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA 
> controller])
> Subsystem: Fujitsu Limited. Device 137a
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 16
> Region 0: Memory at f030 (32-bit, non-prefetchable) [size=512K]
> Region 1: I/O ports at 1800 [size=8]
> Region 2: Memory at e000 (32-bit, prefetchable) [size=256M]
> Region 3: Memory at f040 (32-bit, non-prefetchable) [size=256K]
> Expansion ROM at  [disabled]
> Capabilities: 
> Kernel driver in use: i915
[...]

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic

[git pull] drm for rc1

[Anca Emanuel]

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 of trouble. ?If it works before the pull of Dave's tree, 
>> can you bisect?
>
> There's no way to bisect this thing - it started happening after 2
> hours (first message at 8287.139375 seconds from boot, to be exact).
> So far only once, but that's possibly because I've been asleep for the
> last eight hours ;)
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
>
> And as mentioned, this is a regular machine, not one of my
> preproduction things that tend to have odd silicon or BIOSes.
> Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
> part of that machine is the silent case ;)
>
> Chris wrote:
>> Linus, is anything else kicked off upon powersaving? A screen saver or is
>> it just the blanking that triggers the mess?
>
> So I don't _know_ that it was the screen saver that triggered, but I
> do know that it started happening while I was out to pick up a kid
> from gymnastics. So the screen saver was pretty much the only thing
> going on apart from an idle desktop with a few terminals and chrome.
>
> And it's not even a 3D screen saver or anything graphically fancy,
> it's just the "show random photos" one (it eventually does blank too,
> but I think I've set the blanking interval to an hour or something).
> But compiz was on.
>
> ? ? ? ? ? ? ? ? ? ? ? ? Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>

Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
until is more stable ?

[PATCH] drm/radeon/kms: remove duplicate card_posted() functions

[Alex Deucher]

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(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index cd94065..9546089 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3002,31 +3002,6 @@ int evergreen_copy_blit(struct radeon_device *rdev,
return 0;
 }

-static bool evergreen_card_posted(struct radeon_device *rdev)
-{
-   u32 reg;
-
-   /* first check CRTCs */
-   if (rdev->flags & RADEON_IS_IGP)
-   reg = RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC0_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC1_REGISTER_OFFSET);
-   else
-   reg = RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC0_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC1_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC2_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC3_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC4_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC5_REGISTER_OFFSET);
-   if (reg & EVERGREEN_CRTC_MASTER_EN)
-   return true;
-
-   /* then check MEM_SIZE, in case the crtcs are off */
-   if (RREG32(CONFIG_MEMSIZE))
-   return true;
-
-   return false;
-}
-
 /* Plan is to move initialization in that function and use
  * helper function so that radeon_device_init pretty much
  * do nothing more than calling asic specific function. This
@@ -3063,7 +3038,7 @@ int evergreen_init(struct radeon_device *rdev)
if (radeon_asic_reset(rdev))
dev_warn(rdev->dev, "GPU reset failed !\n");
/* Post card if necessary */
-   if (!evergreen_card_posted(rdev)) {
+   if (!radeon_card_posted(rdev)) {
if (!rdev->bios) {
dev_err(rdev->dev, "Card not posted and no BIOS - 
ignoring\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 248c3f5..203f6a4 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2359,24 +2359,6 @@ void r600_clear_surface_reg(struct radeon_device *rdev, 
int reg)
/* FIXME: implement */
 }

-
-bool r600_card_posted(struct radeon_device *rdev)
-{
-   uint32_t reg;
-
-   /* first check CRTCs */
-   reg = RREG32(D1CRTC_CONTROL) |
-   RREG32(D2CRTC_CONTROL);
-   if (reg & CRTC_EN)
-   return true;
-
-   /* then check MEM_SIZE, in case the crtcs are off */
-   if (RREG32(CONFIG_MEMSIZE))
-   return true;
-
-   return false;
-}
-
 int r600_startup(struct radeon_device *rdev)
 {
int r;
@@ -2537,7 +2519,7 @@ int r600_init(struct radeon_device *rdev)
if (r)
return r;
/* Post card if necessary */
-   if (!r600_card_posted(rdev)) {
+   if (!radeon_card_posted(rdev)) {
if (!rdev->bios) {
dev_err(rdev->dev, "Card not posted and no BIOS - 
ignoring\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 3a264aa..3bf7828 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1268,7 +1268,7 @@ int rv770_init(struct radeon_device *rdev)
if (r)
return r;
/* Post card if necessary */
-   if (!r600_card_posted(rdev)) {
+   if (!radeon_card_posted(rdev)) {
if (!rdev->bios) {
dev_err(rdev->dev, "Card not posted and no BIOS - 
ignoring\n");
return -EINVAL;
-- 
1.7.1.1

[Bug 24414] [Regression] Memory error; stellarium and googleearth crash with mesa 7.6 on Radeon Mobility 7500 1002:4c57

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24414

Ian Romanick  changed:

   What|Removed |Added

   Keywords||NEEDINFO
 CC||idr at freedesktop.org

--- Comment #16 from Ian Romanick  2011-01-11 17:41:38 
PST ---
Is this still reproducible with, say, Mesa 7.9.1 or Mesa 7.10?  A lot has
happened since Mesa 7.7.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Linux 2.6.37

[Chris Wilson]

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 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/show_bug.cgi?id=22672.
> > I can reproduce the problem easily by:
> > xset dpms force standby; sleep 3s; xset dpms force on
> > 
> > backlight doesn't get up (there is really dark picture though which
> > doesn't get brighter by function keys which work normally) after dpms on
> > until I close and open lid. 
> > 
> > The problem wasn't present in 2.6.36
> 
> I can confirm that this problem is not present if both patches from
> bko#22672 are applied on top of 2.6.37 kernel.
> I haven't tried both patches separately, but I can surely try it if it
> makes any sense.

The second patch is wrong in that it will prevent changing resolutions
using the panel fitter. The first patch looks along the right lines, just
misses the possibility that the backlight can be modified by other means.

So hopefully, you just need the first patch.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] drm for rc1

[Linus Torvalds]

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 more intense
screen saver testing is coming up..

   Linus

[git pull] drm for rc1

[Dave Airlie]

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: 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.

 I get millions of messages like:

 ?...
 ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 30938, at 30938],
>>>missed
 IRQ?
 ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31068, at 31068],
>>>missed
 IRQ?
 ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31129, at 31129],
>>>missed
 IRQ?
 ?...

 and everything is very choppy. I assume it's the power saving thing
 that broke again, but that's just a total random guess, I have
>>>nothing
 to actually back that up with.

 It worked fine after boot, but those problems began at 8287.139375
 (about two hours after boot - it may have coincided with screen
>>>saver,
 but who knows?) ?and have been happening constantly since. The
>>>machine
 is not really usable, I'm writing this with annoying 2-second pauses
 every once in a while.
>>>
>>>Okay I'll try and reproduce and curse Chris and Jesse, does booting
>>>with
>>>i915.powersave=0 help any?
>>>
>>>Dave.
>>
>> 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 you bisect?
>>
>
> I think he'd fixed them in the tree I pulled locally to test, I'm
> guessing this might be that we are running the Fedora userspace driver
> and you guys are all on master or something, which would mean some ABI
> guarantee got busted.
>
> I'm going to try a local test upgrade to 2.14.0 just to see.

Okay that didn't help, dead in similar times, evince with a few flood
maps from Brisbane seem to be a good trigger.

I'm not sure I'll be in a good place for bisection, need laptop to
keep track of disaster.

Dave.

A query on frame buffers

[Prasad Joshi]

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 other PCI devices
>> > that means the IOMMU is working. This narrows it down.
>>
>> Yes I could pass-through a network card to VM. I also tried passing
>> through a old Sound Card to Windows 7 machine. It did not work as
>> expected, Windows 7 does not have the old drivers.
>
> Heh.
>>
>> >
>> > The big difference between other PCI devices and the graphics card
>> > is that the graphic card has its own VMM and "radeon_gart_bind" ends
>> > up programming the bus address (so virt_to_phys of the pages, and
>> > you could put in a printk there to see what it is) in the graphic
>> > VMM. This means that when the graphic card is told to fetch the
>> > writeback data it ends up using the address that was programmed
>> > in there to look. Here the IOMMU should step in and see "oh, this
>> > DMA address is for this guest, let me patch it up and actually
>> > look where this would fall in the guest space. Oh OK, let me use
>> > this value real value which correspond the guests real value."
>>
>> It will take some time for me to understand every thing you have written :)
>
> Ok. Ping me if you have some questions. Reading this might
> help (or confuse you more): http://wiki.xensource.com/xenwiki/XenPVOPSDRM
>
>>
>> >
>> > But the IOMMU has a couple of knobs. One of those is the passthrough
>> > code and the GFX mapping code. The first should be easy to spot (should
>> > tell you on bootup whether you got that enabled or not), while the other
>> > looks to be a bunch of workarounds when passing in GFX cards b/c they ..
>> > well, not sure what, but they look to not work correctly with the IOMMU.
>>
>> By GFX Mapping,
>> Do you mean the code that maps VGA frame-buffers to Guest OS?
>
> No. It is the IOMMU kernel code that checks to see if this is a GFX
> card and if so does something fancy. But the workarounds for this appear
> to be exclusive to Intel chipset so you shouldn't hit any.
>
>>
>> One more silly question on the frame-buffer mapping.
>>
>> I was reading a paper on xen vga pass-though. It says "When applying
>> PCI pass-through, certain memory areas of the physical machine are
>> mapped to the VM. When the guest OS writes to one of those memory
>> addresses, Xen will make sure it is actually written at the
>> appropriate address. This implicates that no other VM is able to make
>> use of that device. The frame-buffer is mapped to the machine's main
>> memory at address 0xA to 0xC. This memory range must be mapped
>> to the VM's memory in order for the OS to address the video adapter."
> 
>>
>> My question is
>> In my case, the host machine is using Nvidia graphics card, so the
>> host frame-buffer memory 0xA to 0xC is being actively used by
>> host. Now if the ATI card maps it's framebuffer to this same address
>> wouldn't it cause any problem.
>
> Ah, but it does not. The first card that is called by the BIOS (so your
> motherboard BIOS) sets itself up to use that memory. The other card has
> to wait. Keep in mind that the A to C is the old style VGA
> framebuffer (80x25) or if you program the card properly it can do
> VESA graphics, but nothing else. Usually the guest gets a Cirrus Logic
> video card passed in which sets this device up (and touching that
> area in the guest ends up in VNC window or SDL window).
>
> Anyhow back to your host..
> If you grep in your kernel log you should see something like:
> [drm] fb mappable at 0xE0142000
>
> This is the framebuffer address.
>>
>> If the the machine has only 1 graphics card those statement make
>> sense, but I could not understand what will happen when there are two
>> graphics cards, each connected to different monitor and assigned to
>> different VM, where would each machines frame-buffer reside in the
>> host memory.
>
> Check the kernel log. Usually it is also the first BAR in the pci device.
>
>>
>> Does Xen allow passing-though multiple graphics cards, each to different VM?
>
> Yes (with some patches posted by the AMD and Intel folks)..
> (look for threads that have some GFX or Radeon or something like that in its 
> title).
>>
>> >
>> > If you see 'identity map for device' where the device is your GFX
>> > then that looks to be the bug. It shouldn't set the identity mapping on it.
>> >
>>
>> I guess the identity map is used only on the Intel chipset. Here are
>> msgs on host machine when addition debugging parameter
>> (amd_iommu_dump) was added.
>>
>> prasad at prasad-kvm:~$ dmesg | grep -i -e iommu -e dmar -e amd
>> [ ? ?0.00] Command line: BOOT_IMAGE=/vmlinuz-2.6.37-rc6+
>> root=/dev/sda1 ro iommu=1 amd_iommu_dump
>> [ ? ?0.00] ACPI: SRAT bfe9f8b0 00108 (v01 AMD ? ?FAM_F_10
>> 0002 AMD ?0001)
>> [ ? 

[git pull] drm for rc1

[Dave Airlie]

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: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support
>>>
>>> Lowlights: it's broken.
>>>
>>> I get millions of messages like:
>>>
>>> ?...
>>> ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>>> timer elapsed... render ring idle [waiting on 30938, at 30938],
>>missed
>>> IRQ?
>>> ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>>> timer elapsed... render ring idle [waiting on 31068, at 31068],
>>missed
>>> IRQ?
>>> ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>>> timer elapsed... render ring idle [waiting on 31129, at 31129],
>>missed
>>> IRQ?
>>> ?...
>>>
>>> and everything is very choppy. I assume it's the power saving thing
>>> that broke again, but that's just a total random guess, I have
>>nothing
>>> to actually back that up with.
>>>
>>> It worked fine after boot, but those problems began at 8287.139375
>>> (about two hours after boot - it may have coincided with screen
>>saver,
>>> but who knows?) ?and have been happening constantly since. The
>>machine
>>> is not really usable, I'm writing this with annoying 2-second pauses
>>> every once in a while.
>>
>>Okay I'll try and reproduce and curse Chris and Jesse, does booting
>>with
>>i915.powersave=0 help any?
>>
>>Dave.
>
> 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 you bisect?
>

I think he'd fixed them in the tree I pulled locally to test, I'm
guessing this might be that we are running the Fedora userspace driver
and you guys are all on master or something, which would mean some ABI
guarantee got busted.

I'm going to try a local test upgrade to 2.14.0 just to see.

Dave.

Linux 2.6.37

[Alex Riesen]

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".

Linux 2.6.37

[Michal Hocko]

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 cards
> > backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
> > 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).

I am using intel X11 driver:
[...]
(II) Loading extension DRI2
(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[...]

So this doesn't look like the case.

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic

[git pull] drm for rc1

[Linus Torvalds]

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/resume.
> I also see lots of TRAP messages. (see below).
> X11 seems to work fine though...

Can you try to bisect?

It's a *bit* easier to do if you start out at the drm merge, and only
bisect that part, ie

  MERGE=5b2eef966cb2ae307aa4ef1767f7307774bc96ca
  git bisect start
  git bisect bad $MERGE^2
  git bisect good $MERGE^1

(the above assumes that the merge itself isn't what caused the
problems) and that way you should only need to bisect through the
actual new DRM commits.

   Linus

No subject

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 memory on the host?

So host in this case refers to the Hypervisor and it does not care
about the DMA or what - it does not have any device drivers(*) or such.
The first guest (dom0) is the one that deals with the device drivers.

*: It has one: the serial port, but that is not really that important
for this discussion.
> 
> 
> 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 discrete card GART, not the poor man AMD IOMMU?)
The PCI space is under the 4GB, so it would be considered coherent by
definition.

However the PCI space with its BARs eats in the 4GB space, so if you
have a 1GB region from 0xC->0x10, then you only have 3GB
left of DMA32 zone.

If I think of this as an accounting, and if the PCI space goes further
down (say 0x4, so from 2GB->4GB it is a E820 gap, and 0GB->2GB is System RAM
with 4GB->6GB being the other System RAM, for a cumulative number of 4GB
of memory in the machine), we would only have 2GB of DMA32 zone (The GFP_KERNEL
zone is 4GB, while GFP_DMA32 zone is 2GB).

Then the answer is yes. However, wouldn't such device be 64-bit? And
if they are 64-bit, then the TTM API wouldn't bother to allocate pages
from the 32-bit region, right?

> 
> >>/Thomas
> >>
> >>*) I think gem's flink still is vulnerable to this, though, so it
> >Is there a good test-case for this?
> 
> 
> Not put in code. What you can do (for example in an openGL app) is
> to write some code that tries to flink with a guessed bo name until
> it succeeds. Then repeatedly from within the app, try to flink the
> same name until something crashes. I don't think the linux OOM
> killer can handle that situation. Should be fairly easy to put
> together.

Uhhh, OK, you just flew over what I know about graphics. Let me
research this a bit more.

> 
> /Thomas

[git pull] drm for rc1

[Linus Torvalds]

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 patch that turned the
BUG_ON() into a jerky experience. But I'll test that drm-intel-staging
commit.

  Linus

[git pull] drm for rc1

[Dave Airlie]

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 support
>>> nouveau: reworked VRAM and VM support
>>> intel: better ILK/SNB powersaving support, Full GTT support
>>
>> Lowlights: it's broken.
>>
>> I get millions of messages like:
>>
>> ?...
>> ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 30938, at 30938], missed
>> IRQ?
>> ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 31068, at 31068], missed
>> IRQ?
>> ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 31129, at 31129], missed
>> IRQ?
>> ?...
>>
>> and everything is very choppy. I assume it's the power saving thing
>> that broke again, but that's just a total random guess, I have nothing
>> to actually back that up with.
>>
>> It worked fine after boot, but those problems began at 8287.139375
>> (about two hours after boot - it may have coincided with screen saver,
>> but who knows?) ?and have been happening constantly since. The machine
>> is not really usable, I'm writing this with annoying 2-second pauses
>> every once in a while.
>
> Okay I'll try and reproduce and curse Chris and Jesse, does booting with
> i915.powersave=0 help any?

I've also noticed Chris has some more patches in drm-intel-next I
haven't got in this pull request.

I don't think he's sent me a pull request though so not telling how
stable they are.

Dave.

[git pull] drm for rc1

[Dave Airlie]

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: better ILK/SNB powersaving support, Full GTT support
>
> Lowlights: it's broken.
>
> I get millions of messages like:
>
> ?...
> ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> timer elapsed... render ring idle [waiting on 30938, at 30938], missed
> IRQ?
> ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> timer elapsed... render ring idle [waiting on 31068, at 31068], missed
> IRQ?
> ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> timer elapsed... render ring idle [waiting on 31129, at 31129], missed
> IRQ?
> ?...
>
> and everything is very choppy. I assume it's the power saving thing
> that broke again, but that's just a total random guess, I have nothing
> to actually back that up with.
>
> It worked fine after boot, but those problems began at 8287.139375
> (about two hours after boot - it may have coincided with screen saver,
> but who knows?) ?and have been happening constantly since. The machine
> is not really usable, I'm writing this with annoying 2-second pauses
> every once in a while.

Okay I'll try and reproduce and curse Chris and Jesse, does booting with
i915.powersave=0 help any?

Dave.

[git pull] drm for rc1

[Pavel Machek]

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 this point I expected Linus to complain about milion merges in
changelog...

> 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 you bisect?

Watermarking code? What goes on there?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Linux 2.6.37

[Pavel Machek]

> 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/show_bug.cgi?id=22672.
> 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).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Alex Deucher]

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 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 discrete card GART, not the poor man AMD 
>> >> > IOMMU?)
>> >> > The PCI space is under the 4GB, so it would be considered coherent by
>> >> > definition.
>> >>
>> >> GART is not a PCI BAR; it's just a remapper for system pages. ?On
>> >> radeon GPUs at least there is a memory controller with 3 programmable
>> >> apertures: vram, internal gart, and agp gart. ?You can map these
>> >
>> > To access it, ie, to program it, you would need to access the PCIe card
>> > MMIO regions, right? So that would be considered in PCI BAR space?
>>
>> yes, you need access to the mmio aperture to configure the gpu. ?I was
>> thinking you mean something akin the the framebuffer BAR only for gart
>> space which is not the case.
>
> Aaah, gotcha.
>>
>> >
>> >> resources whereever you want in the GPU's address space and then the
>> >> memory controller takes care of the translation to off-board resources
>> >> like gart pages. ?On chip memory clients (display controllers, texture
>> >> blocks, render blocks, etc.) write to internal GPU addresses. ?The GPU
>> >> has it's own direct connection to vram, so that's not an issue. ?For
>> >> AGP, the GPU specifies aperture base and size, and you point it to the
>> >> bus address of gart aperture provided by the northbridge's AGP
>> >> controller. ?For internal gart, the GPU has a page table stored in
>> >
>> > I think we are just talking about the GART on the GPU, not the old AGP
>> > GART.
>>
>> Ok. ?I just mentioned it for completeness.
>
> 
>>
>> >
>> >> either vram or uncached system memory depending on the asic. ?It
>> >> provides a contiguous linear aperture to GPU clients and the memory
>> >> controller translates the transactions to the backing pages via the
>> >> pagetable.
>> >
>> > So I think I misunderstood what is meant by 'huge gart'. That sounds
>> > like linear address space provided by GPU. And hooking up a lot of coherent
>> > memory (so System RAM) to that linear address space would be no different 
>> > that what
>> > is currently being done. When you allocate memory using 
>> > page_alloc(GFP_DMA32)
>> > and hook up that memory to the linear space you exhaust the same amount of
>> > ZONE_DMA32 memory as if you were to use the PCI API. It comes from the same
>> > pool, except that doing it from the PCI API gets you the bus address right
>> > away.
>> >
>>
>> In this case GPU clients refers to the hw blocks on the GPU; they are
>> the ones that see the contiguous linear aperture. ?From the
>> application's perspective, gart memory looks like any other pages.
>
> . Those 'hw blocks' or 'gart memory' are in reality
> just pages received via the 'alloc_page()' (before this patchset and
> also after this patchset) Oh wait, this 'hw blocks' or 'gart memory' can also
> refer to the VRAM memory right? In which case that is not memory allocated via
> 'alloc_page' but using a different mechanism. Is TTM used then? If so how
> do you stick those VRAM pages under its accounting rules? Or do the drivers
> use some other mechanism for that that is dependent on each driver?
>

"hw blocks" refers to the different sections of the GPU (texture
fetchers, render targets, display controllers), not memory buffers.
E.g., if you want to read a texture from vram or gart, you'd program
the texture base address to the address of the texture in the GPU's
address space.  E.g., you might map 512 MB of vram at from 0x
and a 512 MB gart aperture at 0x2000 in the GPU's address space.
If you have a texture at the start of vram, you'd program the texture
base address to 0x000 or if it was at the start of the gart
aperture, you'd program it to 0x2000.  To the GPU, the gart looks
like a linear array, but to everything else (driver, apps), it's just
pages.  The driver manages vram access using ttm.  The GPU has access
to the entire amount of vram directly, but the CPU can only access it
via the PCI framebuffer BAR.  On systems with more vram than
framebuffer BAR space, the CPU can only access buffers in the region
covered
by the BAR (usually the first 128 or 256 MB of vram depending on the
BAR).  For the CPU to access a buffer in vram, the GPU has to move it
to the area covered by the BAR or to gart memory.

Alex

[git pull] drm for rc1

[Linus Torvalds]

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, since it's not entirely clear how long I
need to wait for the screen saver to cause the problem, but sine I hit
a very similar issue while bisecting, I think it's a pretty solid
(partial) bisect.

What _seems_ to go on is that after commit b5ba177d8d71 ("drm/i915:
Poll for seqno completion if IRQ is disabled") I get that "very chunky
behavior". And _before_ that commit I actually get a BUG_ON(), and in
fact that bug-on does not happen during normal use, but does trigger
when the screen saver runs. So I think the old BUG_ON() is actually
the exact same case that then causes the jerky problem for me.

NOTE! I didn't do a full bisect. I did verify that commit b5ba177d8d71
does expose the bad behavior, and I also verified that a few commits
before that gets the BUG_ON, but there's something like three or four
commits in between that I didn't test. But we're literally talking
just three commits or so (eg commit 8d5203ca6253 gets that BUG_ON(),
and 71f4566084eb is marked as "good" too for me, so the only untested
commits are 9097eef024db and b13c2b96bf15).

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.

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.

Linus

---
[  330.023447] [ cut here ]
[  330.025136] kernel BUG at drivers/gpu/drm/i915/intel_ringbuffer.c:354!
[  330.026758] invalid opcode:  [#1] PREEMPT SMP
[  330.028396] last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[  330.030040] CPU 2
[  330.030049] Modules linked in: [last unloaded: scsi_wait_scan]
[  330.033313]
[  330.034929] Pid: 2723, comm: Xorg Not tainted
2.6.37-rc4-00295-g0cdab21 #16 P7H57D-V EVO/System Product Name
[  330.036581] RIP: 0010:[]  []
render_ring_put_irq+0x20/0x88
[  330.038266] RSP: 0018:88023e001cf8  EFLAGS: 00010246
[  330.039937] RAX:  RBX: 88023fcdc030 RCX: 
[  330.041607] RDX: 3736 RSI: 0001 RDI: 88023fcdc030
[  330.043277] RBP: 88023e001d18 R08: 88023fcdd84c R09: 
[  330.044917] R10: 88023e001cb8 R11: 88023e001cc8 R12: 88023fcdc000
[  330.046571] R13: 88023ff69000 R14: 88023fcdd84c R15: 88023fcdc118
[  330.048193] FS:  7fe1b6342860() GS:8800bd90()
knlGS:
[  330.049822] CS:  0010 DS:  ES:  CR0: 80050033
[  330.051450] CR2: 7f4379961000 CR3: 000229d41000 CR4: 06e0
[  330.053088] DR0:  DR1:  DR2: 
[  330.054726] DR3:  DR6: 0ff0 DR7: 0400
[  330.056364] Process Xorg (pid: 2723, threadinfo 88023e00,
task 880229db2c40)
[  330.057991] Stack:
[  330.059610]  88023fcdc030 88023fcdc000 26b7
88023fcdd84c
[  330.061255]  88023e001d98 812da704 88023e001e18
8802
[  330.062908]   880229db2c40 81051e35
88023e001d50
[  330.064566] Call Trace:
[  330.066202]  [] i915_gem_throttle_ioctl+0x163/0x1ac
[  330.067863]  [] ? autoremove_wake_function+0x0/0x34
[  330.069510]  [] drm_ioctl+0x290/0x35c
[  330.071136]  [] ? lock_hrtimer_base.clone.29+0x24/0x48
[  330.072769]  [] ? i915_gem_throttle_ioctl+0x0/0x1ac
[  330.074397]  [] ? lock_hrtimer_base.clone.29+0x24/0x48
[  330.076025]  [] ? _raw_spin_unlock_irq+0x2b/0x53
[  330.077651]  [] do_vfs_ioctl+0x4c1/0x502
[  330.079252]  [] ? fget_light+0x13a/0x31a
[  330.080845]  [] ? sysret_check+0x27/0x62
[  330.082416]  [] sys_ioctl+0x51/0x76
[  330.083964]  [] system_call_fastpath+0x16/0x1b
[  330.085501] Code: d7 f3 ab 5b 5b 41 5c 41 5d c9 c3 55 48 89 e5 41
56 41 55 41 54 53 4c 8b 6f 18 41 83 bd e0 02 00 00 00 74 66 8b 47 60
85 c0 75 02 <0f> 0b ff c8 89 47 60 85 c0 75 54 49 8b 9d 98 05 00 00 4c
8d a3
[  330.087351] RIP  [] render_ring_put_irq+0x20/0x88
[  330.089039]  RSP 
[  330.099760] ---[ end trace acfb1e4669bf8ace ]---
[  330.376659] [drm:drm_release] *ERROR* Device busy: 1

[git pull] drm for rc1

[Chris Wilson]

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 powersaving support, Full GTT support
> > >>
> > >> Lowlights: it's broken.
> 
> Heh, at this point I expected Linus to complain about milion merges in
> changelog...

Applying bug fixes to one tree and pushing those to 2.6.37 and doing
feature work in another which also depend upon those same bug fixes...
The merges I felt were fairly infrequent, either after a pull request and
subsequent fast-forward of -fixes (so that -next was always a superset of
the current upstream rc) or I applied a patch to -fixes that would
conflict with -next. After those, I did an immediate merge to resolve the
conflict whilst the code was still fresh.

The whole point of trying to keep two trees intact is to be able to
perform continuous testing on both. No matter how hard I try not to, it
seems I always break Linus's machine.

> > 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 you bisect?
> 
> Watermarking code? What goes on there?

FIFO watermarks, they determine when the display fetches from the scanout
buffer to fill the pipe. If we run out of FIFO entries then the display
flickers at best, at worst we may hard hang the machine.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/radeon/kms: balance asic_reset functions

[Alex Deucher]

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 calling mc_stop().

Second, if the reset failed, we were returning without
re-enabling the MC clients.  This patch re-enables
the MC clients before returning regardless of whether
the reset was successful or not.

Signed-off-by: Alex Deucher 
Cc: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r100.c  |   11 ++-
 drivers/gpu/drm/radeon/r300.c  |   11 ++-
 drivers/gpu/drm/radeon/rs600.c |   16 
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index f637595..46da514 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2086,12 +2086,13 @@ int r100_asic_reset(struct radeon_device *rdev)
 {
struct r100_mc_save save;
u32 status, tmp;
+   int ret = 0;

-   r100_mc_stop(rdev, );
status = RREG32(R_000E40_RBBM_STATUS);
if (!G_000E40_GUI_ACTIVE(status)) {
return 0;
}
+   r100_mc_stop(rdev, );
status = RREG32(R_000E40_RBBM_STATUS);
dev_info(rdev->dev, "(%s:%d) RBBM_STATUS=0x%08X\n", __func__, __LINE__, 
status);
/* stop CP */
@@ -2131,11 +2132,11 @@ int r100_asic_reset(struct radeon_device *rdev)
G_000E40_TAM_BUSY(status) || G_000E40_PB_BUSY(status)) {
dev_err(rdev->dev, "failed to reset GPU\n");
rdev->gpu_lockup = true;
-   return -1;
-   }
+   ret = -1;
+   } else
+   dev_info(rdev->dev, "GPU reset succeed\n");
r100_mc_resume(rdev, );
-   dev_info(rdev->dev, "GPU reset succeed\n");
-   return 0;
+   return ret;
 }

 void r100_set_common_regs(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index fae5e70..cf862ca 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -405,12 +405,13 @@ int r300_asic_reset(struct radeon_device *rdev)
 {
struct r100_mc_save save;
u32 status, tmp;
+   int ret = 0;

-   r100_mc_stop(rdev, );
status = RREG32(R_000E40_RBBM_STATUS);
if (!G_000E40_GUI_ACTIVE(status)) {
return 0;
}
+   r100_mc_stop(rdev, );
status = RREG32(R_000E40_RBBM_STATUS);
dev_info(rdev->dev, "(%s:%d) RBBM_STATUS=0x%08X\n", __func__, __LINE__, 
status);
/* stop CP */
@@ -451,11 +452,11 @@ int r300_asic_reset(struct radeon_device *rdev)
if (G_000E40_GA_BUSY(status) || G_000E40_VAP_BUSY(status)) {
dev_err(rdev->dev, "failed to reset GPU\n");
rdev->gpu_lockup = true;
-   return -1;
-   }
+   ret = -1;
+   } else
+   dev_info(rdev->dev, "GPU reset succeed\n");
r100_mc_resume(rdev, );
-   dev_info(rdev->dev, "GPU reset succeed\n");
-   return 0;
+   return ret;
 }

 /*
diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
index b4192ac..5afe294 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -339,16 +339,16 @@ void rs600_bm_disable(struct radeon_device *rdev)

 int rs600_asic_reset(struct radeon_device *rdev)
 {
-   u32 status, tmp;
-
struct rv515_mc_save save;
+   u32 status, tmp;
+   int ret = 0;

-   /* Stops all mc clients */
-   rv515_mc_stop(rdev, );
status = RREG32(R_000E40_RBBM_STATUS);
if (!G_000E40_GUI_ACTIVE(status)) {
return 0;
}
+   /* Stops all mc clients */
+   rv515_mc_stop(rdev, );
status = RREG32(R_000E40_RBBM_STATUS);
dev_info(rdev->dev, "(%s:%d) RBBM_STATUS=0x%08X\n", __func__, __LINE__, 
status);
/* stop CP */
@@ -392,11 +392,11 @@ int rs600_asic_reset(struct radeon_device *rdev)
if (G_000E40_GA_BUSY(status) || G_000E40_VAP_BUSY(status)) {
dev_err(rdev->dev, "failed to reset GPU\n");
rdev->gpu_lockup = true;
-   return -1;
-   }
+   ret = -1;
+   } else
+   dev_info(rdev->dev, "GPU reset succeed\n");
rv515_mc_resume(rdev, );
-   dev_info(rdev->dev, "GPU reset succeed\n");
-   return 0;
+   return ret;
 }

 /*
-- 
1.7.1.1

[RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Konrad Rzeszutek Wilk]

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 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 discrete card GART, not the poor man AMD 
> >> > IOMMU?)
> >> > The PCI space is under the 4GB, so it would be considered coherent by
> >> > definition.
> >>
> >> GART is not a PCI BAR; it's just a remapper for system pages. ?On
> >> radeon GPUs at least there is a memory controller with 3 programmable
> >> apertures: vram, internal gart, and agp gart. ?You can map these
> >
> > To access it, ie, to program it, you would need to access the PCIe card
> > MMIO regions, right? So that would be considered in PCI BAR space?
> 
> yes, you need access to the mmio aperture to configure the gpu.  I was
> thinking you mean something akin the the framebuffer BAR only for gart
> space which is not the case.

Aaah, gotcha.
> 
> >
> >> resources whereever you want in the GPU's address space and then the
> >> memory controller takes care of the translation to off-board resources
> >> like gart pages. ?On chip memory clients (display controllers, texture
> >> blocks, render blocks, etc.) write to internal GPU addresses. ?The GPU
> >> has it's own direct connection to vram, so that's not an issue. ?For
> >> AGP, the GPU specifies aperture base and size, and you point it to the
> >> bus address of gart aperture provided by the northbridge's AGP
> >> controller. ?For internal gart, the GPU has a page table stored in
> >
> > I think we are just talking about the GART on the GPU, not the old AGP
> > GART.
> 
> Ok.  I just mentioned it for completeness.


> 
> >
> >> either vram or uncached system memory depending on the asic. ?It
> >> provides a contiguous linear aperture to GPU clients and the memory
> >> controller translates the transactions to the backing pages via the
> >> pagetable.
> >
> > So I think I misunderstood what is meant by 'huge gart'. That sounds
> > like linear address space provided by GPU. And hooking up a lot of coherent
> > memory (so System RAM) to that linear address space would be no different 
> > that what
> > is currently being done. When you allocate memory using 
> > page_alloc(GFP_DMA32)
> > and hook up that memory to the linear space you exhaust the same amount of
> > ZONE_DMA32 memory as if you were to use the PCI API. It comes from the same
> > pool, except that doing it from the PCI API gets you the bus address right
> > away.
> >
> 
> In this case GPU clients refers to the hw blocks on the GPU; they are
> the ones that see the contiguous linear aperture.  From the
> application's perspective, gart memory looks like any other pages.

. Those 'hw blocks' or 'gart memory' are in reality
just pages received via the 'alloc_page()' (before this patchset and 
also after this patchset) Oh wait, this 'hw blocks' or 'gart memory' can also
refer to the VRAM memory right? In which case that is not memory allocated via
'alloc_page' but using a different mechanism. Is TTM used then? If so how
do you stick those VRAM pages under its accounting rules? Or do the drivers
use some other mechanism for that that is dependent on each driver?

A query on frame buffers

[Konrad Rzeszutek Wilk]

> > 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.

Also, Xen's QEMU has different mechanism for handling PCI passthrough
so ... 

Lots of variables to figure out why it does not work for you.
It might make sense to start first with a working case and from there
start switching over to KVM.

[RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Alex Deucher]

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 in one of the BARs of the device right?
>> > (We are talking about the discrete card GART, not the poor man AMD IOMMU?)
>> > The PCI space is under the 4GB, so it would be considered coherent by
>> > definition.
>>
>> GART is not a PCI BAR; it's just a remapper for system pages. ?On
>> radeon GPUs at least there is a memory controller with 3 programmable
>> apertures: vram, internal gart, and agp gart. ?You can map these
>
> To access it, ie, to program it, you would need to access the PCIe card
> MMIO regions, right? So that would be considered in PCI BAR space?

yes, you need access to the mmio aperture to configure the gpu.  I was
thinking you mean something akin the the framebuffer BAR only for gart
space which is not the case.

>
>> resources whereever you want in the GPU's address space and then the
>> memory controller takes care of the translation to off-board resources
>> like gart pages. ?On chip memory clients (display controllers, texture
>> blocks, render blocks, etc.) write to internal GPU addresses. ?The GPU
>> has it's own direct connection to vram, so that's not an issue. ?For
>> AGP, the GPU specifies aperture base and size, and you point it to the
>> bus address of gart aperture provided by the northbridge's AGP
>> controller. ?For internal gart, the GPU has a page table stored in
>
> I think we are just talking about the GART on the GPU, not the old AGP
> GART.

Ok.  I just mentioned it for completeness.

>
>> either vram or uncached system memory depending on the asic. ?It
>> provides a contiguous linear aperture to GPU clients and the memory
>> controller translates the transactions to the backing pages via the
>> pagetable.
>
> So I think I misunderstood what is meant by 'huge gart'. That sounds
> like linear address space provided by GPU. And hooking up a lot of coherent
> memory (so System RAM) to that linear address space would be no different 
> that what
> is currently being done. When you allocate memory using page_alloc(GFP_DMA32)
> and hook up that memory to the linear space you exhaust the same amount of
> ZONE_DMA32 memory as if you were to use the PCI API. It comes from the same
> pool, except that doing it from the PCI API gets you the bus address right
> away.
>

In this case GPU clients refers to the hw blocks on the GPU; they are
the ones that see the contiguous linear aperture.  From the
application's perspective, gart memory looks like any other pages.

Alex

[git pull] drm for rc1

[Anca Emanuel]

With kernel 2.6.37-git5, my PC hangs.
( I have an nvidia 8800GT and nouveau )

Foto attached.
-- next part --
A non-text attachment was scrubbed...
Name: screen.JPG
Type: image/jpeg
Size: 106271 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110111/3a2dc40e/attachment-0001.jpeg>

A query on frame buffers

[Alex Deucher]

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?
>>
>>> > Since you mentioned that you were able to passthrough other PCI devices
>>> > that means the IOMMU is working. This narrows it down.
>>>
>>> Yes I could pass-through a network card to VM. I also tried passing
>>> through a old Sound Card to Windows 7 machine. It did not work as
>>> expected, Windows 7 does not have the old drivers.
>>
>> Heh.
>>>
>>> >
>>> > The big difference between other PCI devices and the graphics card
>>> > is that the graphic card has its own VMM and "radeon_gart_bind" ends
>>> > up programming the bus address (so virt_to_phys of the pages, and
>>> > you could put in a printk there to see what it is) in the graphic
>>> > VMM. This means that when the graphic card is told to fetch the
>>> > writeback data it ends up using the address that was programmed
>>> > in there to look. Here the IOMMU should step in and see "oh, this
>>> > DMA address is for this guest, let me patch it up and actually
>>> > look where this would fall in the guest space. Oh OK, let me use
>>> > this value real value which correspond the guests real value."
>>>
>>> It will take some time for me to understand every thing you have written :)
>>
>> Ok. Ping me if you have some questions. Reading this might
>> help (or confuse you more): http://wiki.xensource.com/xenwiki/XenPVOPSDRM
>>
>>>
>>> >
>>> > But the IOMMU has a couple of knobs. One of those is the passthrough
>>> > code and the GFX mapping code. The first should be easy to spot (should
>>> > tell you on bootup whether you got that enabled or not), while the other
>>> > looks to be a bunch of workarounds when passing in GFX cards b/c they ..
>>> > well, not sure what, but they look to not work correctly with the IOMMU.
>>>
>>> By GFX Mapping,
>>> Do you mean the code that maps VGA frame-buffers to Guest OS?
>>
>> No. It is the IOMMU kernel code that checks to see if this is a GFX
>> card and if so does something fancy. But the workarounds for this appear
>> to be exclusive to Intel chipset so you shouldn't hit any.
>>
>>>
>>> One more silly question on the frame-buffer mapping.
>>>
>>> I was reading a paper on xen vga pass-though. It says "When applying
>>> PCI pass-through, certain memory areas of the physical machine are
>>> mapped to the VM. When the guest OS writes to one of those memory
>>> addresses, Xen will make sure it is actually written at the
>>> appropriate address. This implicates that no other VM is able to make
>>> use of that device. The frame-buffer is mapped to the machine's main
>>> memory at address 0xA to 0xC. This memory range must be mapped
>>> to the VM's memory in order for the OS to address the video adapter."
>> 
>>>
>>> My question is
>>> In my case, the host machine is using Nvidia graphics card, so the
>>> host frame-buffer memory 0xA to 0xC is being actively used by
>>> host. Now if the ATI card maps it's framebuffer to this same address
>>> wouldn't it cause any problem.
>>
>> Ah, but it does not. The first card that is called by the BIOS (so your
>> motherboard BIOS) sets itself up to use that memory. The other card has
>> to wait. Keep in mind that the A to C is the old style VGA
>> framebuffer (80x25) or if you program the card properly it can do
>> VESA graphics, but nothing else. Usually the guest gets a Cirrus Logic
>> video card passed in which sets this device up (and touching that
>> area in the guest ends up in VNC window or SDL window).
>>
>> Anyhow back to your host..
>> If you grep in your kernel log you should see something like:
>> [drm] fb mappable at 0xE0142000
>>
>> This is the framebuffer address.
>>>
>>> If the the machine has only 1 graphics card those statement make
>>> sense, but I could not understand what will happen when there are two
>>> graphics cards, each connected to different monitor and assigned to
>>> different VM, where would each machines frame-buffer reside in the
>>> host memory.
>>
>> Check the kernel log. Usually it is also the first BAR in the pci device.
>>
>>>
>>> Does Xen allow passing-though multiple graphics cards, each to different VM?
>>
>> Yes (with some patches posted by the AMD and Intel folks)..
>> (look for threads that have some GFX or Radeon or something like that in its 
>> title).
>>>
>>> >
>>> > If you see 'identity map for device' where the device is your GFX
>>> > then that looks to be the bug. It shouldn't set the identity mapping on 
>>> > it.
>>> >
>>>
>>> I guess the identity map is used only on the Intel chipset. Here are
>>> msgs on host machine when addition debugging parameter
>>> (amd_iommu_dump) was added.
>>>
>>> prasad at prasad-kvm:~$ dmesg | grep -i -e iommu -e dmar -e amd
>>> [ ? ?0.00] Command line: 

[RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Konrad Rzeszutek Wilk]

> >> 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 discrete card GART, not the poor man AMD IOMMU?)
> > The PCI space is under the 4GB, so it would be considered coherent by
> > definition.
> 
> GART is not a PCI BAR; it's just a remapper for system pages.  On
> radeon GPUs at least there is a memory controller with 3 programmable
> apertures: vram, internal gart, and agp gart.  You can map these

To access it, ie, to program it, you would need to access the PCIe card
MMIO regions, right? So that would be considered in PCI BAR space?

> resources whereever you want in the GPU's address space and then the
> memory controller takes care of the translation to off-board resources
> like gart pages.  On chip memory clients (display controllers, texture
> blocks, render blocks, etc.) write to internal GPU addresses.  The GPU
> has it's own direct connection to vram, so that's not an issue.  For
> AGP, the GPU specifies aperture base and size, and you point it to the
> bus address of gart aperture provided by the northbridge's AGP
> controller.  For internal gart, the GPU has a page table stored in

I think we are just talking about the GART on the GPU, not the old AGP
GART.

> either vram or uncached system memory depending on the asic.  It
> provides a contiguous linear aperture to GPU clients and the memory
> controller translates the transactions to the backing pages via the
> pagetable.

So I think I misunderstood what is meant by 'huge gart'. That sounds
like linear address space provided by GPU. And hooking up a lot of coherent
memory (so System RAM) to that linear address space would be no different that 
what
is currently being done. When you allocate memory using page_alloc(GFP_DMA32)
and hook up that memory to the linear space you exhaust the same amount of
ZONE_DMA32 memory as if you were to use the PCI API. It comes from the same
pool, except that doing it from the PCI API gets you the bus address right
away.

[git pull] drm for rc1

[Linus Torvalds]

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 timers are much smaller though so it should
> be active anytime the CPU enters a deep sleep state. ?The clock
> frequency changes in millisecond time too, you can check the status of
> that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.

I assume you meant "info", not "status". If so, that doesn't look all
that interesting:

  [torvalds at i5 linux]$ cat /sys/kernel/debug/dri/0/i915_drpc_info
  HD boost: no
  Boost freq: 0
  HW control enabled: no
  SW control enabled: no
  Gated voltage change: no
  Starting frequency: P0
  Max P-state: P0
  Min P-state: P0
  RS1 VID: 0
  RS2 VID: 38
  Render standby enabled: yes
  [torvalds at i5 linux]$ cat /sys/kernel/debug/dri/0/i915_cur_delayinfo
  Requested P-state: 0
  Requested VID: 0
  Current VID: 37
  Current P-state: 0

(This is in the "working state" - I rebooted because I can't stand
working with a machine that feels like a 110baud terminal).

> I wonder if re-enabling rc6 may have caused your issues? ?That would be:
>
> commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a

I don't have this commit at all, it wasn't part of the merged series.

Linus

[git pull] drm for rc1

[Jesse Barnes]

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 never went
> black - just the random photo thing was on. But no, forcing the screen
> saver on doesn't do it either (ie pressing the "lock screen" icon and
> waiting for a few pictures to cycle).
> 
> 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 timers are much smaller though so it should
be active anytime the CPU enters a deep sleep state.  The clock
frequency changes in millisecond time too, you can check the status of
that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.

I wonder if re-enabling rc6 may have caused your issues?  That would be:

commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
Author: Jesse Barnes 
Date:   Wed Jan 5 12:01:24 2011 -0800

drm/i915: re-enable rc6 support for Ironlake+

-- 
Jesse Barnes, Intel Open Source Technology Center

[git pull] drm for rc1

[Linus Torvalds]

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 screen
saver on doesn't do it either (ie pressing the "lock screen" icon and
waiting for a few pictures to cycle).

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"?

   Linus

[RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Alex Deucher]

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_KERNEL does not contain the GFP_DMA32 flag then
>> >this should be OK?
>>
>> No, Unless I miss something, on a machine with 4GB or less,
>> GFP_DMA32 and GFP_KERNEL are allocated from the same pool of pages?
>
> Yes. Depending on the E820 and where the PCI hole is present. More
> details below.
>>
>> >
>> >>What *might* be possible, however, is that the GFP_KERNEL memory on
>> >>the host gets exhausted due to extensive TTM allocations in the
>> >>guest, but I guess that's a problem for XEN to resolve, not TTM.
>> >Hmm. I think I am missing something here. The GFP_KERNEL is any memory
>> >and the GFP_DMA32 is memory from the ZONE_DMA32. When we do start
>> >using the PCI-API, what happens underneath (so under Linux) is that
>> >"real PFNs" (Machine Frame Numbers) which are above the 0x10 mark
>> >get swizzled in for the guest's PFNs (this is for the PCI devices
>> >that have the dma_mask set to 32bit). However, that is a Xen MMU
>> >accounting issue.
>>
>>
>> So I was under the impression that when you allocate coherent memory
>> in the guest, the physical page comes from DMA32 memory in the host.
>
> No. It comes from DMA32 zone off the hypervisor pool. If say you have a 
> machine
> with 24GB, the first guest (Dom0) could allocate memory from 20->24GB
> (so only 4GB allocated to it). It will then also fetch 64MB from the DMA32
> zone for the SWIOTLB. Then the next guest, say 4GB (gets 16GB->20GB) - gets
> 64MB from DMA32. And ?so on.
>
> So at the end we have 16GB taken from 8GB->24GB, and 320MB taken from
> 0->4GB. When you start allocating coherent memory from each guest
> (and yeah, say we use 2GB each), we end up with the first guest getting
> the 2GB, the second getting 1.7GB, and then the next two getting zil.
>
> You still have GFP_KERNEL memory in each guest - the first one has 2GB left
> , then second 2.3, the next two have each 4GB.
>
> From the hyprevisor pool perspective, the 0-4GB zone is exhausted, so
> 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 memory on the host?
>
> So host in this case refers to the Hypervisor and it does not care
> about the DMA or what - it does not have any device drivers(*) or such.
> The first guest (dom0) is the one that deals with the device drivers.
>
> *: It has one: the serial port, but that is not really that important
> for this discussion.
>>
>>
>> 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 discrete card GART, not the poor man AMD IOMMU?)
> The PCI space is under the 4GB, so it would be considered coherent by
> definition.

GART is not a PCI BAR; it's just a remapper for system pages.  On
radeon GPUs at least there is a memory controller with 3 programmable
apertures: vram, internal gart, and agp gart.  You can map these
resources whereever you want in the GPU's address space and then the
memory controller takes care of the translation to off-board resources
like gart pages.  On chip memory clients (display controllers, texture
blocks, render blocks, etc.) write to internal GPU addresses.  The GPU
has it's own direct connection to vram, so that's not an issue.  For
AGP, the GPU specifies aperture base and size, and you point it to the
bus address of gart aperture provided by the northbridge's AGP
controller.  For internal gart, the GPU has a page table stored in
either vram or uncached system memory depending on the asic.  It
provides a contiguous linear aperture to GPU clients and the memory
controller translates the transactions to the backing pages via the
pagetable.

Alex

>
> However the PCI space with its BARs eats in the 4GB space, so if you
> have a 1GB region from 0xC->0x10, then you only have 3GB
> left of DMA32 zone.
>
> If I think of this as an accounting, and if the PCI space goes further
> down (say 0x4, so from 2GB->4GB it is a E820 gap, and 0GB->2GB is System 
> RAM
> with 4GB->6GB being the other System RAM, for a cumulative number of 4GB
> of memory in the machine), we would only have 2GB of DMA32 zone (The 
> GFP_KERNEL
> zone is 4GB, while GFP_DMA32 zone is 2GB).
>
> Then the answer is yes. However, wouldn't such device be 64-bit? And
> if they are 64-bit, then the TTM API wouldn't bother to allocate pages
> from the 32-bit region, right?
>
>>

[git pull] drm for rc1

[Jesse Barnes]

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 while I was
> away from the machine and the screen saver was running. So it does
> seem to have something to do with power-saving modes or something.

Have you tried reproducing it using xset dpms force off or similar?

Chris, what are you using to trigger the watermark related issues
you've found?

-- 
Jesse Barnes, Intel Open Source Technology Center

[git pull] drm for rc1

[Linus Torvalds]

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 does
seem to have something to do with power-saving modes or something.

 Linus

[git pull] drm for rc1

[Chris Wilson]

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 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.
> >>
> >> I get millions of messages like:
> >>
> >> ??...
> >> ??[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> >> timer elapsed... render ring idle [waiting on 30938, at 30938], missed
> >> IRQ?
> >> ??[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> >> timer elapsed... render ring idle [waiting on 31068, at 31068], missed
> >> IRQ?
> >> ??[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> >> timer elapsed... render ring idle [waiting on 31129, at 31129], missed
> >> IRQ?
> >> ??...
> >>
> >> and everything is very choppy. I assume it's the power saving thing
> >> that broke again, but that's just a total random guess, I have nothing
> >> to actually back that up with.
> >>
> >> It worked fine after boot, but those problems began at 8287.139375
> >> (about two hours after boot - it may have coincided with screen saver,
> >> but who knows?) ??and have been happening constantly since. The machine
> >> is not really usable, I'm writing this with annoying 2-second pauses
> >> every once in a while.
> >
> > Okay I'll try and reproduce and curse Chris and Jesse, does booting with
> > i915.powersave=0 help any?
> 
> I've also noticed Chris has some more patches in drm-intel-next I
> haven't got in this pull request.
> 
> I don't think he's sent me a pull request though so not telling how
> stable they are.

Yes, there are a few pending fixes. I've been waiting on feedback from
testing for some more before asking for a pull. In part because we have
some more eDP fixes, courtesy of Jesse, that makes everyone but Jim Getty
happy.

However, I've not seen anything like this so I doubt that d-i-n contains
the fix.

Dave, is yours related to the DMAR errors that is plaguing your systems?

Linus, is anything else kicked off upon powersaving? A screen saver or is
it just the blanking that triggers the mess?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Konrad Rzeszutek Wilk]

. 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?
> 
> No, Unless I miss something, on a machine with 4GB or less,
> GFP_DMA32 and GFP_KERNEL are allocated from the same pool of pages?

Yes. Depending on the E820 and where the PCI hole is present. More
details below.
> 
> >
> >>What *might* be possible, however, is that the GFP_KERNEL memory on
> >>the host gets exhausted due to extensive TTM allocations in the
> >>guest, but I guess that's a problem for XEN to resolve, not TTM.
> >Hmm. I think I am missing something here. The GFP_KERNEL is any memory
> >and the GFP_DMA32 is memory from the ZONE_DMA32. When we do start
> >using the PCI-API, what happens underneath (so under Linux) is that
> >"real PFNs" (Machine Frame Numbers) which are above the 0x10 mark
> >get swizzled in for the guest's PFNs (this is for the PCI devices
> >that have the dma_mask set to 32bit). However, that is a Xen MMU
> >accounting issue.
> 
> 
> So I was under the impression that when you allocate coherent memory
> in the guest, the physical page comes from DMA32 memory in the host.

No. It comes from DMA32 zone off the hypervisor pool. If say you have a machine
with 24GB, the first guest (Dom0) could allocate memory from 20->24GB
(so only 4GB allocated to it). It will then also fetch 64MB from the DMA32
zone for the SWIOTLB. Then the next guest, say 4GB (gets 16GB->20GB) - gets
64MB from DMA32. And  so on.

So at the end we have 16GB taken from 8GB->24GB, and 320MB taken from 
0->4GB. When you start allocating coherent memory from each guest
(and yeah, say we use 2GB each), we end up with the first guest getting
the 2GB, the second getting 1.7GB, and then the next two getting zil.

You still have GFP_KERNEL memory in each guest - the first one has 2GB left
, then second 2.3, the next two have each 4GB.

[PATCH] drm/radeon/kms: Initialize pageflip spinlocks.

[Michel Dänzer]

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/radeon_irq_kms.c
index a289646..9ec830c 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -110,11 +110,14 @@ void radeon_driver_irq_uninstall_kms(struct drm_device 
*dev)

 int radeon_irq_kms_init(struct radeon_device *rdev)
 {
+   int i;
int r = 0;

INIT_WORK(>hotplug_work, radeon_hotplug_work_func);

spin_lock_init(>irq.sw_lock);
+   for (i = 0; i < rdev->num_crtc; i++)
+   spin_lock_init(>irq.pflip_lock[i]);
r = drm_vblank_init(rdev->ddev, rdev->num_crtc);
if (r) {
return r;
-- 
1.7.2.3

[Bug 32918] gnome-shell / mutter crashing.

[bugzilla-dae...@freedesktop.org]

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://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 17819] R300 Colourspace problem

[bugzilla-dae...@freedesktop.org]

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
this bug (suspending/resuming), so maybe should we close this one as duplicate
of #32871, especially since there're been no answer on this one for more than
one year...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[git pull] drm for rc1

[Linus Torvalds]

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 you bisect?

There's no way to bisect this thing - it started happening after 2
hours (first message at 8287.139375 seconds from boot, to be exact).
So far only once, but that's possibly because I've been asleep for the
last eight hours ;)

But yes, it worked before pulling Dave's tree, IOW, I haven't seen
this message on this machine before.

And as mentioned, this is a regular machine, not one of my
preproduction things that tend to have odd silicon or BIOSes.
Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
part of that machine is the silent case ;)

Chris wrote:
> Linus, is anything else kicked off upon powersaving? A screen saver or is
> it just the blanking that triggers the mess?

So I don't _know_ that it was the screen saver that triggered, but I
do know that it started happening while I was out to pick up a kid
from gymnastics. So the screen saver was pretty much the only thing
going on apart from an idle desktop with a few terminals and chrome.

And it's not even a 3D screen saver or anything graphically fancy,
it's just the "show random photos" one (it eventually does blank too,
but I think I've set the blanking interval to an hour or something).
But compiz was on.

 Linus

[PATCH] drm/radeon/kms: Initialize pageflip spinlocks.

[Michel Dänzer]

From: Michel Dänzer daen...@vmware.com

I'm amazed but not really surprised this worked on x86...

Signed-off-by: Michel Dänzer daen...@vmware.com
---
 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/radeon_irq_kms.c
index a289646..9ec830c 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -110,11 +110,14 @@ void radeon_driver_irq_uninstall_kms(struct drm_device 
*dev)
 
 int radeon_irq_kms_init(struct radeon_device *rdev)
 {
+   int i;
int r = 0;
 
INIT_WORK(rdev-hotplug_work, radeon_hotplug_work_func);
 
spin_lock_init(rdev-irq.sw_lock);
+   for (i = 0; i  rdev-num_crtc; i++)
+   spin_lock_init(rdev-irq.pflip_lock[i]);
r = drm_vblank_init(rdev-ddev, rdev-num_crtc);
if (r) {
return r;
-- 
1.7.2.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:51:40 +1000, Dave Airlie airl...@gmail.com wrote:
 On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie airl...@gmail.com wrote:
  On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
  torva...@linux-foundation.org wrote:
  On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie wrote:
  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.
 
  I get millions of messages like:
 
   ...
   [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
  timer elapsed... render ring idle [waiting on 30938, at 30938], missed
  IRQ?
   [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
  timer elapsed... render ring idle [waiting on 31068, at 31068], missed
  IRQ?
   [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
  timer elapsed... render ring idle [waiting on 31129, at 31129], missed
  IRQ?
   ...
 
  and everything is very choppy. I assume it's the power saving thing
  that broke again, but that's just a total random guess, I have nothing
  to actually back that up with.
 
  It worked fine after boot, but those problems began at 8287.139375
  (about two hours after boot - it may have coincided with screen saver,
  but who knows?)  and have been happening constantly since. The machine
  is not really usable, I'm writing this with annoying 2-second pauses
  every once in a while.
 
  Okay I'll try and reproduce and curse Chris and Jesse, does booting with
  i915.powersave=0 help any?
 
 I've also noticed Chris has some more patches in drm-intel-next I
 haven't got in this pull request.
 
 I don't think he's sent me a pull request though so not telling how
 stable they are.

Yes, there are a few pending fixes. I've been waiting on feedback from
testing for some more before asking for a pull. In part because we have
some more eDP fixes, courtesy of Jesse, that makes everyone but Jim Getty
happy.

However, I've not seen anything like this so I doubt that d-i-n contains
the fix.

Dave, is yours related to the DMAR errors that is plaguing your systems?

Linus, is anything else kicked off upon powersaving? A screen saver or is
it just the blanking that triggers the mess?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Pavel Machek]

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 this point I expected Linus to complain about milion merges in
changelog...

 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 you bisect?

Watermarking code? What goes on there?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

[Pavel Machek]

 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/show_bug.cgi?id=22672.
 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).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:33:29 +0100, Pavel Machek pa...@ucw.cz 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 powersaving support, Full GTT support
  
   Lowlights: it's broken.
 
 Heh, at this point I expected Linus to complain about milion merges in
 changelog...

Applying bug fixes to one tree and pushing those to 2.6.37 and doing
feature work in another which also depend upon those same bug fixes...
The merges I felt were fairly infrequent, either after a pull request and
subsequent fast-forward of -fixes (so that -next was always a superset of
the current upstream rc) or I applied a patch to -fixes that would
conflict with -next. After those, I did an immediate merge to resolve the
conflict whilst the code was still fresh.

The whole point of trying to keep two trees intact is to be able to
perform continuous testing on both. No matter how hard I try not to, it
seems I always break Linus's machine.

  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 you bisect?
 
 Watermarking code? What goes on there?

FIFO watermarks, they determine when the display fetches from the scanout
buffer to fill the pipe. If we run out of FIFO entries then the display
flickers at best, at worst we may hard hang the machine.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

[Michal Hocko]

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 cards
  backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
  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).

I am using intel X11 driver:
[...]
(II) Loading extension DRI2
(II) LoadModule: intel
(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[...]

So this doesn't look like the case.

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

[Alex Riesen]

On Tue, Jan 11, 2011 at 14:33, Pavel Machek pa...@ucw.cz 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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Konrad Rzeszutek Wilk]

. 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?
 
 No, Unless I miss something, on a machine with 4GB or less,
 GFP_DMA32 and GFP_KERNEL are allocated from the same pool of pages?

Yes. Depending on the E820 and where the PCI hole is present. More
details below.
 
 
 What *might* be possible, however, is that the GFP_KERNEL memory on
 the host gets exhausted due to extensive TTM allocations in the
 guest, but I guess that's a problem for XEN to resolve, not TTM.
 Hmm. I think I am missing something here. The GFP_KERNEL is any memory
 and the GFP_DMA32 is memory from the ZONE_DMA32. When we do start
 using the PCI-API, what happens underneath (so under Linux) is that
 real PFNs (Machine Frame Numbers) which are above the 0x10 mark
 get swizzled in for the guest's PFNs (this is for the PCI devices
 that have the dma_mask set to 32bit). However, that is a Xen MMU
 accounting issue.
 
 
 So I was under the impression that when you allocate coherent memory
 in the guest, the physical page comes from DMA32 memory in the host.

No. It comes from DMA32 zone off the hypervisor pool. If say you have a machine
with 24GB, the first guest (Dom0) could allocate memory from 20-24GB
(so only 4GB allocated to it). It will then also fetch 64MB from the DMA32
zone for the SWIOTLB. Then the next guest, say 4GB (gets 16GB-20GB) - gets
64MB from DMA32. And  so on.

So at the end we have 16GB taken from 8GB-24GB, and 320MB taken from 
0-4GB. When you start allocating coherent memory from each guest
(and yeah, say we use 2GB each), we end up with the first guest getting
the 2GB, the second getting 1.7GB, and then the next two getting zil.

You still have GFP_KERNEL memory in each guest - the first one has 2GB left
, then second 2.3, the next two have each 4GB.

From the hyprevisor pool perspective, the 0-4GB zone is exhausted, so
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 memory on the host?

So host in this case refers to the Hypervisor and it does not care
about the DMA or what - it does not have any device drivers(*) or such.
The first guest (dom0) is the one that deals with the device drivers.

*: It has one: the serial port, but that is not really that important
for this discussion.
 
 
 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?

scratches his head

So the GART is in the PCI space in one of the BARs of the device right?
(We are talking about the discrete card GART, not the poor man AMD IOMMU?)
The PCI space is under the 4GB, so it would be considered coherent by
definition.

However the PCI space with its BARs eats in the 4GB space, so if you
have a 1GB region from 0xC-0x10, then you only have 3GB
left of DMA32 zone.

If I think of this as an accounting, and if the PCI space goes further
down (say 0x4, so from 2GB-4GB it is a E820 gap, and 0GB-2GB is System RAM
with 4GB-6GB being the other System RAM, for a cumulative number of 4GB
of memory in the machine), we would only have 2GB of DMA32 zone (The GFP_KERNEL
zone is 4GB, while GFP_DMA32 zone is 2GB).

Then the answer is yes. However, wouldn't such device be 64-bit? And
if they are 64-bit, then the TTM API wouldn't bother to allocate pages
from the 32-bit region, right?

 
 /Thomas
 
 *) I think gem's flink still is vulnerable to this, though, so it
 Is there a good test-case for this?
 
 
 Not put in code. What you can do (for example in an openGL app) is
 to write some code that tries to flink with a guessed bo name until
 it succeeds. Then repeatedly from within the app, try to flink the
 same name until something crashes. I don't think the linux OOM
 killer can handle that situation. Should be fairly easy to put
 together.

Uhhh, OK, you just flew over what I know about graphics. Let me
research this a bit more.

 
 /Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes jbar...@virtuousgeek.org 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 you bisect?

There's no way to bisect this thing - it started happening after 2
hours (first message at 8287.139375 seconds from boot, to be exact).
So far only once, but that's possibly because I've been asleep for the
last eight hours ;)

But yes, it worked before pulling Dave's tree, IOW, I haven't seen
this message on this machine before.

And as mentioned, this is a regular machine, not one of my
preproduction things that tend to have odd silicon or BIOSes.
Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
part of that machine is the silent case ;)

Chris wrote:
 Linus, is anything else kicked off upon powersaving? A screen saver or is
 it just the blanking that triggers the mess?

So I don't _know_ that it was the screen saver that triggered, but I
do know that it started happening while I was out to pick up a kid
from gymnastics. So the screen saver was pretty much the only thing
going on apart from an idle desktop with a few terminals and chrome.

And it's not even a 3D screen saver or anything graphically fancy,
it's just the show random photos one (it eventually does blank too,
but I think I've set the blanking interval to an hour or something).
But compiz was on.

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 17819] R300 Colourspace problem

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=17819

--- Comment #3 from Thierry Vignaud thierry.vign...@gmail.com 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
this bug (suspending/resuming), so maybe should we close this one as duplicate
of #32871, especially since there're been no answer on this one for more than
one year...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Alex Deucher]

On Tue, Jan 11, 2011 at 10:55 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com 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_KERNEL does not contain the GFP_DMA32 flag then
 this should be OK?

 No, Unless I miss something, on a machine with 4GB or less,
 GFP_DMA32 and GFP_KERNEL are allocated from the same pool of pages?

 Yes. Depending on the E820 and where the PCI hole is present. More
 details below.

 
 What *might* be possible, however, is that the GFP_KERNEL memory on
 the host gets exhausted due to extensive TTM allocations in the
 guest, but I guess that's a problem for XEN to resolve, not TTM.
 Hmm. I think I am missing something here. The GFP_KERNEL is any memory
 and the GFP_DMA32 is memory from the ZONE_DMA32. When we do start
 using the PCI-API, what happens underneath (so under Linux) is that
 real PFNs (Machine Frame Numbers) which are above the 0x10 mark
 get swizzled in for the guest's PFNs (this is for the PCI devices
 that have the dma_mask set to 32bit). However, that is a Xen MMU
 accounting issue.


 So I was under the impression that when you allocate coherent memory
 in the guest, the physical page comes from DMA32 memory in the host.

 No. It comes from DMA32 zone off the hypervisor pool. If say you have a 
 machine
 with 24GB, the first guest (Dom0) could allocate memory from 20-24GB
 (so only 4GB allocated to it). It will then also fetch 64MB from the DMA32
 zone for the SWIOTLB. Then the next guest, say 4GB (gets 16GB-20GB) - gets
 64MB from DMA32. And  so on.

 So at the end we have 16GB taken from 8GB-24GB, and 320MB taken from
 0-4GB. When you start allocating coherent memory from each guest
 (and yeah, say we use 2GB each), we end up with the first guest getting
 the 2GB, the second getting 1.7GB, and then the next two getting zil.

 You still have GFP_KERNEL memory in each guest - the first one has 2GB left
 , then second 2.3, the next two have each 4GB.

 From the hyprevisor pool perspective, the 0-4GB zone is exhausted, so
 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 memory on the host?

 So host in this case refers to the Hypervisor and it does not care
 about the DMA or what - it does not have any device drivers(*) or such.
 The first guest (dom0) is the one that deals with the device drivers.

 *: It has one: the serial port, but that is not really that important
 for this discussion.


 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?

 scratches his head

 So the GART is in the PCI space in one of the BARs of the device right?
 (We are talking about the discrete card GART, not the poor man AMD IOMMU?)
 The PCI space is under the 4GB, so it would be considered coherent by
 definition.

GART is not a PCI BAR; it's just a remapper for system pages.  On
radeon GPUs at least there is a memory controller with 3 programmable
apertures: vram, internal gart, and agp gart.  You can map these
resources whereever you want in the GPU's address space and then the
memory controller takes care of the translation to off-board resources
like gart pages.  On chip memory clients (display controllers, texture
blocks, render blocks, etc.) write to internal GPU addresses.  The GPU
has it's own direct connection to vram, so that's not an issue.  For
AGP, the GPU specifies aperture base and size, and you point it to the
bus address of gart aperture provided by the northbridge's AGP
controller.  For internal gart, the GPU has a page table stored in
either vram or uncached system memory depending on the asic.  It
provides a contiguous linear aperture to GPU clients and the memory
controller translates the transactions to the backing pages via the
pagetable.

Alex


 However the PCI space with its BARs eats in the 4GB space, so if you
 have a 1GB region from 0xC-0x10, then you only have 3GB
 left of DMA32 zone.

 If I think of this as an accounting, and if the PCI space goes further
 down (say 0x4, so from 2GB-4GB it is a E820 gap, and 0GB-2GB is System 
 RAM
 with 4GB-6GB being the other System RAM, for a cumulative number of 4GB
 of memory in the machine), we would only have 2GB of DMA32 zone (The 
 GFP_KERNEL
 zone is 4GB, while GFP_DMA32 zone is 2GB).

 Then the answer is yes. However, wouldn't such device be 64-bit? And
 if they are 64-bit, then the TTM API wouldn't bother to allocate pages
 from the 32-bit region, right?


 /Thomas
 
 *) I think gem's flink still is vulnerable to this, though, so it
 Is there a good test-case for this?

Re: A query on frame buffers

[Prasad Joshi]

On Mon, Jan 10, 2011 at 8:24 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com 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 other PCI devices
  that means the IOMMU is working. This narrows it down.

 Yes I could pass-through a network card to VM. I also tried passing
 through a old Sound Card to Windows 7 machine. It did not work as
 expected, Windows 7 does not have the old drivers.

 Heh.

 
  The big difference between other PCI devices and the graphics card
  is that the graphic card has its own VMM and radeon_gart_bind ends
  up programming the bus address (so virt_to_phys of the pages, and
  you could put in a printk there to see what it is) in the graphic
  VMM. This means that when the graphic card is told to fetch the
  writeback data it ends up using the address that was programmed
  in there to look. Here the IOMMU should step in and see oh, this
  DMA address is for this guest, let me patch it up and actually
  look where this would fall in the guest space. Oh OK, let me use
  this value real value which correspond the guests real value.

 It will take some time for me to understand every thing you have written :)

 Ok. Ping me if you have some questions. Reading this might
 help (or confuse you more): http://wiki.xensource.com/xenwiki/XenPVOPSDRM


 
  But the IOMMU has a couple of knobs. One of those is the passthrough
  code and the GFX mapping code. The first should be easy to spot (should
  tell you on bootup whether you got that enabled or not), while the other
  looks to be a bunch of workarounds when passing in GFX cards b/c they ..
  well, not sure what, but they look to not work correctly with the IOMMU.

 By GFX Mapping,
 Do you mean the code that maps VGA frame-buffers to Guest OS?

 No. It is the IOMMU kernel code that checks to see if this is a GFX
 card and if so does something fancy. But the workarounds for this appear
 to be exclusive to Intel chipset so you shouldn't hit any.


 One more silly question on the frame-buffer mapping.

 I was reading a paper on xen vga pass-though. It says When applying
 PCI pass-through, certain memory areas of the physical machine are
 mapped to the VM. When the guest OS writes to one of those memory
 addresses, Xen will make sure it is actually written at the
 appropriate address. This implicates that no other VM is able to make
 use of that device. The frame-buffer is mapped to the machine's main
 memory at address 0xA to 0xC. This memory range must be mapped
 to the VM's memory in order for the OS to address the video adapter.
 nods

 My question is
 In my case, the host machine is using Nvidia graphics card, so the
 host frame-buffer memory 0xA to 0xC is being actively used by
 host. Now if the ATI card maps it's framebuffer to this same address
 wouldn't it cause any problem.

 Ah, but it does not. The first card that is called by the BIOS (so your
 motherboard BIOS) sets itself up to use that memory. The other card has
 to wait. Keep in mind that the A to C is the old style VGA
 framebuffer (80x25) or if you program the card properly it can do
 VESA graphics, but nothing else. Usually the guest gets a Cirrus Logic
 video card passed in which sets this device up (and touching that
 area in the guest ends up in VNC window or SDL window).

 Anyhow back to your host..
 If you grep in your kernel log you should see something like:
 [drm] fb mappable at 0xE0142000

 This is the framebuffer address.

 If the the machine has only 1 graphics card those statement make
 sense, but I could not understand what will happen when there are two
 graphics cards, each connected to different monitor and assigned to
 different VM, where would each machines frame-buffer reside in the
 host memory.

 Check the kernel log. Usually it is also the first BAR in the pci device.


 Does Xen allow passing-though multiple graphics cards, each to different VM?

 Yes (with some patches posted by the AMD and Intel folks)..
 (look for threads that have some GFX or Radeon or something like that in its 
 title).

 
  If you see 'identity map for device' where the device is your GFX
  then that looks to be the bug. It shouldn't set the identity mapping on it.
 

 I guess the identity map is used only on the Intel chipset. Here are
 msgs on host machine when addition debugging parameter
 (amd_iommu_dump) was added.

 pra...@prasad-kvm:~$ dmesg | grep -i -e iommu -e dmar -e amd
 [    0.00] Command line: BOOT_IMAGE=/vmlinuz-2.6.37-rc6+
 root=/dev/sda1 ro iommu=1 amd_iommu_dump
 [    0.00] ACPI: SRAT bfe9f8b0 00108 (v01 AMD    FAM_F_10
 0002 AMD  0001)
 [    0.00] ACPI: IVRS bfe9fa00 000D8 (v01  AMD     RD890S
 00202031 AMD  )
 [    0.00] ACPI: SSDT bfe9fae0 00DA4 (v01 A M I  POWERNOW
 0001 AMD  0001)
 [    

Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Konrad Rzeszutek Wilk]

  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?
 
  scratches his head
 
  So the GART is in the PCI space in one of the BARs of the device right?
  (We are talking about the discrete card GART, not the poor man AMD IOMMU?)
  The PCI space is under the 4GB, so it would be considered coherent by
  definition.
 
 GART is not a PCI BAR; it's just a remapper for system pages.  On
 radeon GPUs at least there is a memory controller with 3 programmable
 apertures: vram, internal gart, and agp gart.  You can map these

To access it, ie, to program it, you would need to access the PCIe card
MMIO regions, right? So that would be considered in PCI BAR space?

 resources whereever you want in the GPU's address space and then the
 memory controller takes care of the translation to off-board resources
 like gart pages.  On chip memory clients (display controllers, texture
 blocks, render blocks, etc.) write to internal GPU addresses.  The GPU
 has it's own direct connection to vram, so that's not an issue.  For
 AGP, the GPU specifies aperture base and size, and you point it to the
 bus address of gart aperture provided by the northbridge's AGP
 controller.  For internal gart, the GPU has a page table stored in

I think we are just talking about the GART on the GPU, not the old AGP
GART.

 either vram or uncached system memory depending on the asic.  It
 provides a contiguous linear aperture to GPU clients and the memory
 controller translates the transactions to the backing pages via the
 pagetable.

So I think I misunderstood what is meant by 'huge gart'. That sounds
like linear address space provided by GPU. And hooking up a lot of coherent
memory (so System RAM) to that linear address space would be no different that 
what
is currently being done. When you allocate memory using page_alloc(GFP_DMA32)
and hook up that memory to the linear space you exhaust the same amount of
ZONE_DMA32 memory as if you were to use the PCI API. It comes from the same
pool, except that doing it from the PCI API gets you the bus address right
away.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: A query on frame buffers

[Alex Deucher]

On Tue, Jan 11, 2011 at 11:58 AM, Prasad Joshi prasadjoshi...@gmail.com wrote:
 On Mon, Jan 10, 2011 at 8:24 PM, Konrad Rzeszutek Wilk
 konrad.w...@oracle.com 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 other PCI devices
  that means the IOMMU is working. This narrows it down.

 Yes I could pass-through a network card to VM. I also tried passing
 through a old Sound Card to Windows 7 machine. It did not work as
 expected, Windows 7 does not have the old drivers.

 Heh.

 
  The big difference between other PCI devices and the graphics card
  is that the graphic card has its own VMM and radeon_gart_bind ends
  up programming the bus address (so virt_to_phys of the pages, and
  you could put in a printk there to see what it is) in the graphic
  VMM. This means that when the graphic card is told to fetch the
  writeback data it ends up using the address that was programmed
  in there to look. Here the IOMMU should step in and see oh, this
  DMA address is for this guest, let me patch it up and actually
  look where this would fall in the guest space. Oh OK, let me use
  this value real value which correspond the guests real value.

 It will take some time for me to understand every thing you have written :)

 Ok. Ping me if you have some questions. Reading this might
 help (or confuse you more): http://wiki.xensource.com/xenwiki/XenPVOPSDRM


 
  But the IOMMU has a couple of knobs. One of those is the passthrough
  code and the GFX mapping code. The first should be easy to spot (should
  tell you on bootup whether you got that enabled or not), while the other
  looks to be a bunch of workarounds when passing in GFX cards b/c they ..
  well, not sure what, but they look to not work correctly with the IOMMU.

 By GFX Mapping,
 Do you mean the code that maps VGA frame-buffers to Guest OS?

 No. It is the IOMMU kernel code that checks to see if this is a GFX
 card and if so does something fancy. But the workarounds for this appear
 to be exclusive to Intel chipset so you shouldn't hit any.


 One more silly question on the frame-buffer mapping.

 I was reading a paper on xen vga pass-though. It says When applying
 PCI pass-through, certain memory areas of the physical machine are
 mapped to the VM. When the guest OS writes to one of those memory
 addresses, Xen will make sure it is actually written at the
 appropriate address. This implicates that no other VM is able to make
 use of that device. The frame-buffer is mapped to the machine's main
 memory at address 0xA to 0xC. This memory range must be mapped
 to the VM's memory in order for the OS to address the video adapter.
 nods

 My question is
 In my case, the host machine is using Nvidia graphics card, so the
 host frame-buffer memory 0xA to 0xC is being actively used by
 host. Now if the ATI card maps it's framebuffer to this same address
 wouldn't it cause any problem.

 Ah, but it does not. The first card that is called by the BIOS (so your
 motherboard BIOS) sets itself up to use that memory. The other card has
 to wait. Keep in mind that the A to C is the old style VGA
 framebuffer (80x25) or if you program the card properly it can do
 VESA graphics, but nothing else. Usually the guest gets a Cirrus Logic
 video card passed in which sets this device up (and touching that
 area in the guest ends up in VNC window or SDL window).

 Anyhow back to your host..
 If you grep in your kernel log you should see something like:
 [drm] fb mappable at 0xE0142000

 This is the framebuffer address.

 If the the machine has only 1 graphics card those statement make
 sense, but I could not understand what will happen when there are two
 graphics cards, each connected to different monitor and assigned to
 different VM, where would each machines frame-buffer reside in the
 host memory.

 Check the kernel log. Usually it is also the first BAR in the pci device.


 Does Xen allow passing-though multiple graphics cards, each to different VM?

 Yes (with some patches posted by the AMD and Intel folks)..
 (look for threads that have some GFX or Radeon or something like that in its 
 title).

 
  If you see 'identity map for device' where the device is your GFX
  then that looks to be the bug. It shouldn't set the identity mapping on 
  it.
 

 I guess the identity map is used only on the Intel chipset. Here are
 msgs on host machine when addition debugging parameter
 (amd_iommu_dump) was added.

 pra...@prasad-kvm:~$ dmesg | grep -i -e iommu -e dmar -e amd
 [    0.00] Command line: BOOT_IMAGE=/vmlinuz-2.6.37-rc6+
 root=/dev/sda1 ro iommu=1 amd_iommu_dump
 [    0.00] ACPI: SRAT bfe9f8b0 00108 (v01 AMD    FAM_F_10
 0002 AMD  0001)
 [    0.00] ACPI: IVRS bfe9fa00 000D8 (v01  AMD     RD890S
 00202031 AMD  )
 [    0.00] 

Re: [git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:01 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes jbar...@virtuousgeek.org 
 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 you bisect?

 There's no way to bisect this thing - it started happening after 2
 hours (first message at 8287.139375 seconds from boot, to be exact).
 So far only once, but that's possibly because I've been asleep for the
 last eight hours ;)

 But yes, it worked before pulling Dave's tree, IOW, I haven't seen
 this message on this machine before.

 And as mentioned, this is a regular machine, not one of my
 preproduction things that tend to have odd silicon or BIOSes.
 Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
 part of that machine is the silent case ;)

 Chris wrote:
 Linus, is anything else kicked off upon powersaving? A screen saver or is
 it just the blanking that triggers the mess?

 So I don't _know_ that it was the screen saver that triggered, but I
 do know that it started happening while I was out to pick up a kid
 from gymnastics. So the screen saver was pretty much the only thing
 going on apart from an idle desktop with a few terminals and chrome.

 And it's not even a 3D screen saver or anything graphically fancy,
 it's just the show random photos one (it eventually does blank too,
 but I think I've set the blanking interval to an hour or something).
 But compiz was on.

                         Linus
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/


Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
until is more stable ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:11 PM, Anca Emanuel anca.eman...@gmail.com 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.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect bad 5b2eef966cb2ae307aa4ef1767f7307774bc96ca
# good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37
git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5
# good: [c413521eb4e2d7ffd5ce432a144708d479054bd3] ARM: mach-shmobile:
update for SMP changes.
git bisect good c413521eb4e2d7ffd5ce432a144708d479054bd3
# bad: [78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252] Merge branch
'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect bad 78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252
# bad: [da40d036fd716f0efb2917076220814b1e927ae1] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git bisect bad da40d036fd716f0efb2917076220814b1e927ae1
# bad: [dc69d1af9e8d9cbbabff88bb35a6782187a9] omap2: Make
OMAP2PLUS select OMAP_DM_TIMER
git bisect bad dc69d1af9e8d9cbbabff88bb35a6782187a9

Second bisect bad: nouveau not loaded, but I have an usable system.
I don't feel I'm doing it right.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

[Michal Hocko]

[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 still a regression for intel graphic cards
 backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
 I can reproduce the problem easily by:
 xset dpms force standby; sleep 3s; xset dpms force on
 
 backlight doesn't get up (there is really dark picture though which
 doesn't get brighter by function keys which work normally) after dpms on
 until I close and open lid. 
 
 The problem wasn't present in 2.6.36

I can confirm that this problem is not present if both patches from
bko#22672 are applied on top of 2.6.37 kernel.
I haven't tried both patches separately, but I can surely try it if it
makes any sense.

 
 $ lspci -vv
 [...]
 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA 
 controller])
 Subsystem: Fujitsu Limited. Device 137a
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at f030 (32-bit, non-prefetchable) [size=512K]
 Region 1: I/O ports at 1800 [size=8]
 Region 2: Memory at e000 (32-bit, prefetchable) [size=256M]
 Region 3: Memory at f040 (32-bit, non-prefetchable) [size=256K]
 Expansion ROM at unassigned [disabled]
 Capabilities: access denied
 Kernel driver in use: i915
[...]

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

[Michal Hocko]

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
   regression on intel graphics.
  
  It seems that there is still a regression for intel graphic cards
  backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
  I can reproduce the problem easily by:
  xset dpms force standby; sleep 3s; xset dpms force on
  
  backlight doesn't get up (there is really dark picture though which
  doesn't get brighter by function keys which work normally) after dpms on
  until I close and open lid. 
  
  The problem wasn't present in 2.6.36
 
 I can confirm that this problem is not present if both patches from
 bko#22672 are applied on top of 2.6.37 kernel.
 I haven't tried both patches separately, but I can surely try it if it
 makes any sense.

I have just tried that and they are really both necessary.


-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

[Chris Wilson]

On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko mho...@suse.cz 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
   regression on intel graphics.
  
  It seems that there is still a regression for intel graphic cards
  backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
  I can reproduce the problem easily by:
  xset dpms force standby; sleep 3s; xset dpms force on
  
  backlight doesn't get up (there is really dark picture though which
  doesn't get brighter by function keys which work normally) after dpms on
  until I close and open lid. 
  
  The problem wasn't present in 2.6.36
 
 I can confirm that this problem is not present if both patches from
 bko#22672 are applied on top of 2.6.37 kernel.
 I haven't tried both patches separately, but I can surely try it if it
 makes any sense.

The second patch is wrong in that it will prevent changing resolutions
using the panel fitter. The first patch looks along the right lines, just
misses the possibility that the backlight can be modified by other means.

So hopefully, you just need the first patch.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

[Michal Hocko]

On Tue 11-01-11 17:39:42, Chris Wilson wrote:
 On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko mho...@suse.cz 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
regression on intel graphics.
   
   It seems that there is still a regression for intel graphic cards
   backlight. One report is 
   https://bugzilla.kernel.org/show_bug.cgi?id=22672.
   I can reproduce the problem easily by:
   xset dpms force standby; sleep 3s; xset dpms force on
   
   backlight doesn't get up (there is really dark picture though which
   doesn't get brighter by function keys which work normally) after dpms on
   until I close and open lid. 
   
   The problem wasn't present in 2.6.36
  
  I can confirm that this problem is not present if both patches from
  bko#22672 are applied on top of 2.6.37 kernel.
  I haven't tried both patches separately, but I can surely try it if it
  makes any sense.
 
 The second patch is wrong in that it will prevent changing resolutions
 using the panel fitter. The first patch looks along the right lines, just
 misses the possibility that the backlight can be modified by other means.
 
 So hopefully, you just need the first patch.

I would have bet I have tested the 1st patch but let me double check.
The 2nd patch alone doesn't fix the problem.

 -Chris
 
 -- 
 Chris Wilson, Intel Open Source Technology Centre

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

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

[Bug 32918] gnome-shell / mutter crashing.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32918

--- Comment #7 from Lee Wilson vixsand...@gmail.com 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://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Alex Deucher]

On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com 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?
 
  scratches his head
 
  So the GART is in the PCI space in one of the BARs of the device right?
  (We are talking about the discrete card GART, not the poor man AMD IOMMU?)
  The PCI space is under the 4GB, so it would be considered coherent by
  definition.

 GART is not a PCI BAR; it's just a remapper for system pages.  On
 radeon GPUs at least there is a memory controller with 3 programmable
 apertures: vram, internal gart, and agp gart.  You can map these

 To access it, ie, to program it, you would need to access the PCIe card
 MMIO regions, right? So that would be considered in PCI BAR space?

yes, you need access to the mmio aperture to configure the gpu.  I was
thinking you mean something akin the the framebuffer BAR only for gart
space which is not the case.


 resources whereever you want in the GPU's address space and then the
 memory controller takes care of the translation to off-board resources
 like gart pages.  On chip memory clients (display controllers, texture
 blocks, render blocks, etc.) write to internal GPU addresses.  The GPU
 has it's own direct connection to vram, so that's not an issue.  For
 AGP, the GPU specifies aperture base and size, and you point it to the
 bus address of gart aperture provided by the northbridge's AGP
 controller.  For internal gart, the GPU has a page table stored in

 I think we are just talking about the GART on the GPU, not the old AGP
 GART.

Ok.  I just mentioned it for completeness.


 either vram or uncached system memory depending on the asic.  It
 provides a contiguous linear aperture to GPU clients and the memory
 controller translates the transactions to the backing pages via the
 pagetable.

 So I think I misunderstood what is meant by 'huge gart'. That sounds
 like linear address space provided by GPU. And hooking up a lot of coherent
 memory (so System RAM) to that linear address space would be no different 
 that what
 is currently being done. When you allocate memory using page_alloc(GFP_DMA32)
 and hook up that memory to the linear space you exhaust the same amount of
 ZONE_DMA32 memory as if you were to use the PCI API. It comes from the same
 pool, except that doing it from the PCI API gets you the bus address right
 away.


In this case GPU clients refers to the hw blocks on the GPU; they are
the ones that see the contiguous linear aperture.  From the
application's perspective, gart memory looks like any other pages.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: A query on frame buffers

[Konrad Rzeszutek Wilk]

  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.

Also, Xen's QEMU has different mechanism for handling PCI passthrough
so ... 

Lots of variables to figure out why it does not work for you.
It might make sense to start first with a working case and from there
start switching over to KVM.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Konrad Rzeszutek Wilk]

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
 konrad.w...@oracle.com 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?
  
   scratches his head
  
   So the GART is in the PCI space in one of the BARs of the device right?
   (We are talking about the discrete card GART, not the poor man AMD 
   IOMMU?)
   The PCI space is under the 4GB, so it would be considered coherent by
   definition.
 
  GART is not a PCI BAR; it's just a remapper for system pages.  On
  radeon GPUs at least there is a memory controller with 3 programmable
  apertures: vram, internal gart, and agp gart.  You can map these
 
  To access it, ie, to program it, you would need to access the PCIe card
  MMIO regions, right? So that would be considered in PCI BAR space?
 
 yes, you need access to the mmio aperture to configure the gpu.  I was
 thinking you mean something akin the the framebuffer BAR only for gart
 space which is not the case.

Aaah, gotcha.
 
 
  resources whereever you want in the GPU's address space and then the
  memory controller takes care of the translation to off-board resources
  like gart pages.  On chip memory clients (display controllers, texture
  blocks, render blocks, etc.) write to internal GPU addresses.  The GPU
  has it's own direct connection to vram, so that's not an issue.  For
  AGP, the GPU specifies aperture base and size, and you point it to the
  bus address of gart aperture provided by the northbridge's AGP
  controller.  For internal gart, the GPU has a page table stored in
 
  I think we are just talking about the GART on the GPU, not the old AGP
  GART.
 
 Ok.  I just mentioned it for completeness.

nods
 
 
  either vram or uncached system memory depending on the asic.  It
  provides a contiguous linear aperture to GPU clients and the memory
  controller translates the transactions to the backing pages via the
  pagetable.
 
  So I think I misunderstood what is meant by 'huge gart'. That sounds
  like linear address space provided by GPU. And hooking up a lot of coherent
  memory (so System RAM) to that linear address space would be no different 
  that what
  is currently being done. When you allocate memory using 
  page_alloc(GFP_DMA32)
  and hook up that memory to the linear space you exhaust the same amount of
  ZONE_DMA32 memory as if you were to use the PCI API. It comes from the same
  pool, except that doing it from the PCI API gets you the bus address right
  away.
 
 
 In this case GPU clients refers to the hw blocks on the GPU; they are
 the ones that see the contiguous linear aperture.  From the
 application's perspective, gart memory looks like any other pages.

nods. Those 'hw blocks' or 'gart memory' are in reality
just pages received via the 'alloc_page()' (before this patchset and 
also after this patchset) Oh wait, this 'hw blocks' or 'gart memory' can also
refer to the VRAM memory right? In which case that is not memory allocated via
'alloc_page' but using a different mechanism. Is TTM used then? If so how
do you stick those VRAM pages under its accounting rules? Or do the drivers
use some other mechanism for that that is dependent on each driver?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37

[Michal Hocko]

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 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/show_bug.cgi?id=22672.
   I can reproduce the problem easily by:
   xset dpms force standby; sleep 3s; xset dpms force on
   
   backlight doesn't get up (there is really dark picture though which
   doesn't get brighter by function keys which work normally) after dpms on
   until I close and open lid. 
   
   The problem wasn't present in 2.6.36
  
  I can confirm that this problem is not present if both patches from
  bko#22672 are applied on top of 2.6.37 kernel.
  I haven't tried both patches separately, but I can surely try it if it
  makes any sense.
 
 I have just tried that and they are really both necessary.

I must have mixed something. After retesting with the first patch
(https://bugzilla.kernel.org/show_bug.cgi?id=22672#c33) the usecase
works just fine (backlight is on without need to closeopen the lid)

Sorry for confusion

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
torva...@linux-foundation.org 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 does
seem to have something to do with power-saving modes or something.

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Jesse Barnes]

On Tue, 11 Jan 2011 11:00:13 -0800
Linus Torvalds torva...@linux-foundation.org wrote:

 On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
 torva...@linux-foundation.org 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 does
 seem to have something to do with power-saving modes or something.

Have you tried reproducing it using xset dpms force off or similar?

Chris, what are you using to trigger the watermark related issues
you've found?

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbar...@virtuousgeek.org 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 screen
saver on doesn't do it either (ie pressing the lock screen icon and
waiting for a few pictures to cycle).

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?

   Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Jesse Barnes]

On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds torva...@linux-foundation.org wrote:

 On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbar...@virtuousgeek.org 
 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 screen
 saver on doesn't do it either (ie pressing the lock screen icon and
 waiting for a few pictures to cycle).
 
 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 timers are much smaller though so it should
be active anytime the CPU enters a deep sleep state.  The clock
frequency changes in millisecond time too, you can check the status of
that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.

I wonder if re-enabling rc6 may have caused your issues?  That would be:

commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Wed Jan 5 12:01:24 2011 -0800

drm/i915: re-enable rc6 support for Ironlake+

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes jbar...@virtuousgeek.org 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 timers are much smaller though so it should
 be active anytime the CPU enters a deep sleep state.  The clock
 frequency changes in millisecond time too, you can check the status of
 that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.

I assume you meant info, not status. If so, that doesn't look all
that interesting:

  [torva...@i5 linux]$ cat /sys/kernel/debug/dri/0/i915_drpc_info
  HD boost: no
  Boost freq: 0
  HW control enabled: no
  SW control enabled: no
  Gated voltage change: no
  Starting frequency: P0
  Max P-state: P0
  Min P-state: P0
  RS1 VID: 0
  RS2 VID: 38
  Render standby enabled: yes
  [torva...@i5 linux]$ cat /sys/kernel/debug/dri/0/i915_cur_delayinfo
  Requested P-state: 0
  Requested VID: 0
  Current VID: 37
  Current P-state: 0

(This is in the working state - I rebooted because I can't stand
working with a machine that feels like a 110baud terminal).

 I wonder if re-enabling rc6 may have caused your issues?  That would be:

 commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a

I don't have this commit at all, it wasn't part of the merged series.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 11:45:05 -0800, Jesse Barnes jbar...@virtuousgeek.org 
wrote:
 On Tue, 11 Jan 2011 11:25:39 -0800
 Linus Torvalds torva...@linux-foundation.org wrote:
 
  On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbar...@virtuousgeek.org 
  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 screen
  saver on doesn't do it either (ie pressing the lock screen icon and
  waiting for a few pictures to cycle).
  
  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 timers are much smaller though so it should
 be active anytime the CPU enters a deep sleep state.  The clock
 frequency changes in millisecond time too, you can check the status of
 that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.
 
 I wonder if re-enabling rc6 may have caused your issues?  That would be:
 
 commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
 Author: Jesse Barnes jbar...@virtuousgeek.org
 Date:   Wed Jan 5 12:01:24 2011 -0800
 
 drm/i915: re-enable rc6 support for Ironlake+

We haven't actually got as far as that patch yet, that's waiting for a
suitable juncture to send the request. Now that the trees have converged I
can pick which patches need to go for rc1 and which can wait for -next.

Looking at the set of outstanding patch, my suspect would be the ring irq
refcounting which needed a fix and seems implicated by the error message.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
torva...@linux-foundation.org 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, since it's not entirely clear how long I
need to wait for the screen saver to cause the problem, but sine I hit
a very similar issue while bisecting, I think it's a pretty solid
(partial) bisect.

What _seems_ to go on is that after commit b5ba177d8d71 (drm/i915:
Poll for seqno completion if IRQ is disabled) I get that very chunky
behavior. And _before_ that commit I actually get a BUG_ON(), and in
fact that bug-on does not happen during normal use, but does trigger
when the screen saver runs. So I think the old BUG_ON() is actually
the exact same case that then causes the jerky problem for me.

NOTE! I didn't do a full bisect. I did verify that commit b5ba177d8d71
does expose the bad behavior, and I also verified that a few commits
before that gets the BUG_ON, but there's something like three or four
commits in between that I didn't test. But we're literally talking
just three commits or so (eg commit 8d5203ca6253 gets that BUG_ON(),
and 71f4566084eb is marked as good too for me, so the only untested
commits are 9097eef024db and b13c2b96bf15).

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.

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.

Linus

---
[  330.023447] [ cut here ]
[  330.025136] kernel BUG at drivers/gpu/drm/i915/intel_ringbuffer.c:354!
[  330.026758] invalid opcode:  [#1] PREEMPT SMP
[  330.028396] last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[  330.030040] CPU 2
[  330.030049] Modules linked in: [last unloaded: scsi_wait_scan]
[  330.033313]
[  330.034929] Pid: 2723, comm: Xorg Not tainted
2.6.37-rc4-00295-g0cdab21 #16 P7H57D-V EVO/System Product Name
[  330.036581] RIP: 0010:[812f1cbd]  [812f1cbd]
render_ring_put_irq+0x20/0x88
[  330.038266] RSP: 0018:88023e001cf8  EFLAGS: 00010246
[  330.039937] RAX:  RBX: 88023fcdc030 RCX: 
[  330.041607] RDX: 3736 RSI: 0001 RDI: 88023fcdc030
[  330.043277] RBP: 88023e001d18 R08: 88023fcdd84c R09: 
[  330.044917] R10: 88023e001cb8 R11: 88023e001cc8 R12: 88023fcdc000
[  330.046571] R13: 88023ff69000 R14: 88023fcdd84c R15: 88023fcdc118
[  330.048193] FS:  7fe1b6342860() GS:8800bd90()
knlGS:
[  330.049822] CS:  0010 DS:  ES:  CR0: 80050033
[  330.051450] CR2: 7f4379961000 CR3: 000229d41000 CR4: 06e0
[  330.053088] DR0:  DR1:  DR2: 
[  330.054726] DR3:  DR6: 0ff0 DR7: 0400
[  330.056364] Process Xorg (pid: 2723, threadinfo 88023e00,
task 880229db2c40)
[  330.057991] Stack:
[  330.059610]  88023fcdc030 88023fcdc000 26b7
88023fcdd84c
[  330.061255]  88023e001d98 812da704 88023e001e18
8802
[  330.062908]   880229db2c40 81051e35
88023e001d50
[  330.064566] Call Trace:
[  330.066202]  [812da704] i915_gem_throttle_ioctl+0x163/0x1ac
[  330.067863]  [81051e35] ? autoremove_wake_function+0x0/0x34
[  330.069510]  [812ba08f] drm_ioctl+0x290/0x35c
[  330.071136]  [81054f24] ? lock_hrtimer_base.clone.29+0x24/0x48
[  330.072769]  [812da5a1] ? i915_gem_throttle_ioctl+0x0/0x1ac
[  330.074397]  [81054f24] ? lock_hrtimer_base.clone.29+0x24/0x48
[  330.076025]  [8153c02c] ? _raw_spin_unlock_irq+0x2b/0x53
[  330.077651]  [810d2ed9] do_vfs_ioctl+0x4c1/0x502
[  330.079252]  [810c56cd] ? fget_light+0x13a/0x31a
[  330.080845]  [8100202c] ? sysret_check+0x27/0x62
[  330.082416]  [810d2f6b] sys_ioctl+0x51/0x76
[  330.083964]  [81001ffb] system_call_fastpath+0x16/0x1b
[  330.085501] Code: d7 f3 ab 5b 5b 41 5c 41 5d c9 c3 55 48 89 e5 41
56 41 55 41 54 53 4c 8b 6f 18 41 83 bd e0 02 00 00 00 74 66 8b 47 60
85 c0 75 02 0f 0b ff c8 89 47 60 85 c0 75 54 49 8b 9d 98 05 00 00 4c
8d a3
[  330.087351] RIP  [812f1cbd] render_ring_put_irq+0x20/0x88
[  330.089039]  RSP 88023e001cf8
[  330.099760] ---[ end trace acfb1e4669bf8ace ]---
[  330.376659] [drm:drm_release] *ERROR* Device busy: 1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:16:54 -0800, Linus Torvalds 
torva...@linux-foundation.org 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 fix
for.

I've put the patches up on drm-intel-staging as I begin retesting them
before sending the pull request. In particular you need
01a03331e5fe91861937f8b8e72c259f5e9eae67.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26552] New: Screen flickering with 2.6.37 [ATI X1600]

[bugzilla-daemon]

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
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: andrea_...@yahoo.it
Regression: Yes


Created an attachment (id=43282)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=43282)
dmesg when flickering is present

Starting from 2.6.37 the screen on my Toshiba Satellite A100 flickers as soon
as kernel modesetting is initialized. The flickering does not occur always:
sometimes the screen is almost unreadable, sometimes there is no flickering at
all.

With 2.6.36 (and previous versions) I've never experienced flickering problems.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=26552





--- Comment #1 from Andrea Iob andrea_...@yahoo.it  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.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
torva...@linux-foundation.org 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 patch that turned the
BUG_ON() into a jerky experience. But I'll test that drm-intel-staging
commit.

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: remove duplicate card_posted() functions

[Alex Deucher]

Use the common one for all asics.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 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(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index cd94065..9546089 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3002,31 +3002,6 @@ int evergreen_copy_blit(struct radeon_device *rdev,
return 0;
 }
 
-static bool evergreen_card_posted(struct radeon_device *rdev)
-{
-   u32 reg;
-
-   /* first check CRTCs */
-   if (rdev-flags  RADEON_IS_IGP)
-   reg = RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC0_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC1_REGISTER_OFFSET);
-   else
-   reg = RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC0_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC1_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC2_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC3_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC4_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC5_REGISTER_OFFSET);
-   if (reg  EVERGREEN_CRTC_MASTER_EN)
-   return true;
-
-   /* then check MEM_SIZE, in case the crtcs are off */
-   if (RREG32(CONFIG_MEMSIZE))
-   return true;
-
-   return false;
-}
-
 /* Plan is to move initialization in that function and use
  * helper function so that radeon_device_init pretty much
  * do nothing more than calling asic specific function. This
@@ -3063,7 +3038,7 @@ int evergreen_init(struct radeon_device *rdev)
if (radeon_asic_reset(rdev))
dev_warn(rdev-dev, GPU reset failed !\n);
/* Post card if necessary */
-   if (!evergreen_card_posted(rdev)) {
+   if (!radeon_card_posted(rdev)) {
if (!rdev-bios) {
dev_err(rdev-dev, Card not posted and no BIOS - 
ignoring\n);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 248c3f5..203f6a4 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2359,24 +2359,6 @@ void r600_clear_surface_reg(struct radeon_device *rdev, 
int reg)
/* FIXME: implement */
 }
 
-
-bool r600_card_posted(struct radeon_device *rdev)
-{
-   uint32_t reg;
-
-   /* first check CRTCs */
-   reg = RREG32(D1CRTC_CONTROL) |
-   RREG32(D2CRTC_CONTROL);
-   if (reg  CRTC_EN)
-   return true;
-
-   /* then check MEM_SIZE, in case the crtcs are off */
-   if (RREG32(CONFIG_MEMSIZE))
-   return true;
-
-   return false;
-}
-
 int r600_startup(struct radeon_device *rdev)
 {
int r;
@@ -2537,7 +2519,7 @@ int r600_init(struct radeon_device *rdev)
if (r)
return r;
/* Post card if necessary */
-   if (!r600_card_posted(rdev)) {
+   if (!radeon_card_posted(rdev)) {
if (!rdev-bios) {
dev_err(rdev-dev, Card not posted and no BIOS - 
ignoring\n);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 3a264aa..3bf7828 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1268,7 +1268,7 @@ int rv770_init(struct radeon_device *rdev)
if (r)
return r;
/* Post card if necessary */
-   if (!r600_card_posted(rdev)) {
+   if (!radeon_card_posted(rdev)) {
if (!rdev-bios) {
dev_err(rdev-dev, Card not posted and no BIOS - 
ignoring\n);
return -EINVAL;
-- 
1.7.1.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26552] Screen flickering with 2.6.37 [ATI X1600]

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=26552


Rafael J. Wysocki r...@sisk.pl changed:

   What|Removed |Added

 CC||flor...@mickler.org,
   ||maciej.rute...@gmail.com,
   ||r...@sisk.pl
 Blocks||21782




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
borntrae...@de.ibm.com 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/resume.
 I also see lots of TRAP messages. (see below).
 X11 seems to work fine though...

Can you try to bisect?

It's a *bit* easier to do if you start out at the drm merge, and only
bisect that part, ie

  MERGE=5b2eef966cb2ae307aa4ef1767f7307774bc96ca
  git bisect start
  git bisect bad $MERGE^2
  git bisect good $MERGE^1

(the above assumes that the merge itself isn't what caused the
problems) and that way you should only need to bisect through the
actual new DRM commits.

   Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Christian Borntraeger]

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)
 
 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
 
 There are also some switcheroo patches to further improve it, though I 
 have a later patch blocking on an x86 platform driver for the nvidia/intel 
 switcher.
 
 Dave.

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/resume.
I also see lots of TRAP messages. (see below).
X11 seems to work fine though...

$ dmesg | grep drm
[0.520906] [drm] Initialized drm 1.1.0 20060810
[0.521200] [drm] radeon defaulting to kernel modesetting.
[0.521416] [drm] radeon kernel modesetting enabled.
[0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp 
module!
[0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x084c00a2)
[0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from 
PRAMIN
[0.641884] [drm] nouveau :01:00.0: ... appears to be valid
[0.642058] [drm] nouveau :01:00.0: BIT BIOS found
[0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00
[0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0   


[0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found  


[0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block 
version 4.0 
   
[0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034   


[0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028   


[0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030   


[0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e    


[0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 
2   
 
[0.643836] [drm] nouveau :01:00.0:   0: 0x0040: type 0x40 idx 0 tag 
0xff
[0.644089] [drm] nouveau :01:00.0:   1: 0x0100: type 0x00 idx 1 tag 
0xff
[0.644317] [drm] nouveau :01:00.0:   2: 0x1231: type 0x31 idx 2 tag 
0x07
[0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 
0xDEBB
[0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 
0xE208
[0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 
0xEC55
[0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 
0xED47
[0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 
0xEF7A
[0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
0xEFDF
[0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met 
after 20ms, skipping following opcodes
[0.775483] [drm] nouveau :01:00.0: 3 available performance level(s)
[0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 
338MHz voltage 1150mV fanspeed 100%
[0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 
550MHz voltage 1150mV fanspeed 100%
[0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 
950MHz voltage 1200mV fanspeed 100%
[0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 
550MHz voltage 1150mV
[0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM
[0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
[0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[0.889565] [drm] No driver support for vblank timestamp query.
[0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, 
not registering our own
[1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, 
bo 88013af63400
[1.071842] [drm] nouveau :01:00.0: PGRAPH 

Re: Linux 2.6.37

[Indan Zupancic]

Hello,

On Tue, January 11, 2011 18:39, Chris Wilson wrote:
 On Tue, 11 Jan 2011 18:19:17 +0100, Michal Hocko mho...@suse.cz 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
   regression on intel graphics.
 
  It seems that there is still a regression for intel graphic cards
  backlight. One report is https://bugzilla.kernel.org/show_bug.cgi?id=22672.
  I can reproduce the problem easily by:
  xset dpms force standby; sleep 3s; xset dpms force on
 
  backlight doesn't get up (there is really dark picture though which
  doesn't get brighter by function keys which work normally) after dpms on
  until I close and open lid.
 
  The problem wasn't present in 2.6.36

 I can confirm that this problem is not present if both patches from
 bko#22672 are applied on top of 2.6.37 kernel.
 I haven't tried both patches separately, but I can surely try it if it
 makes any sense.

 The second patch is wrong in that it will prevent changing resolutions
 using the panel fitter.

I can confirm that with the second patch changing resolutions doesn't always go 
right.

$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 
0mm
   1024x768   50.0*+   85.0 75.0 70.1 60.0
   832x62474.6
   800x60085.1 72.2 75.0 60.3 56.2
   640x48085.0 72.8 75.0 59.9
   720x40085.0
   640x40085.1
   640x35085.1
VGA1 disconnected (normal left inverted right x axis y axis)

Going from xrandr -s 1, 2 or 3 back to 0 works, but not from 4, 5 or 6 to 0.

The second patch was really a stab in the dark, I'm happy it was in the right
direction at least.

 The first patch looks along the right lines, just
 misses the possibility that the backlight can be modified by other means.

I'm not sure about that. All it does is avoiding setting backlight_level to
0. If it's modified some other way and intel_panel_get_backlight() returns 0,
backlight_level is just never set and will stay zero. If there is a way to
switch between ways to modify the backlight then I can see how this may not
always work, because then backlight_level is stuck on the last non-zero value
before it was switched to intel_panel_set_backlight(0) and the different method.

Alex reported a slightly dimmer display after resume, so I wonder what I missed
in my patch. Larry's problem was probably fixed with just the first patch, but
then I wonder why he reported that it didn't work first. Maybe he meant the
setpci thing, or made a mistake.

 So hopefully, you just need the first patch.
 -Chris

Yeah, the second patch is a bit of a desperate attempt because Larry reported 
that
it didn't fix his problem.

About your patch, you still do:

+void intel_panel_setup_backlight(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev-dev_private;
+
+   dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+   dev_priv-backlight_enabled = dev_priv-backlight_level != 0;
+}

While my patch changes that to:

+   u32 level;

-   if (dev_priv-backlight_level == 0)
-   dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+   if (dev_priv-backlight_level == 0) {
+   level = intel_panel_get_backlight(dev);
+   if (level == 0)
+   level = intel_panel_get_max_backlight(dev);
+   dev_priv-backlight_level = level;
+   }

Your patch uses intel_panel_get_max_backlight() to check if the backlight is
enabled. Is this always correct, or may it cause bugs in the future?

Anyway, my main concern with unconditionally setting the backlight level to
the maximum is that any stored brightness level (by the BIOS or whatever) may
be lost, and that the screen is set to maximum brightness at each boot. This
is certainly the behaviour I've seen with an unpatched kernel. So I propose to
do what my patch does and set it to intel_panel_get_backlight(dev) if that
returns non-zero. Something like this:

+void intel_panel_setup_backlight(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   u32 max, level;
+
+   max = intel_panel_get_max_backlight(dev);
+   if (max) {
+   dev_priv-backlight_enabled = 1;
+   level = intel_panel_get_backlight(dev);
+   if (!level)
+   level = max;
+   dev_priv-backlight_level = level;
+   }
+}

While I'm glad this problem is being fixed upstream, it would be nice to get
some credit for finding the source of the problem.

Greetings,

Indan


___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
torva...@linux-foundation.org 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 more intense
screen saver testing is coming up..

   Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 24414] [Regression] Memory error; stellarium and googleearth crash with mesa 7.6 on Radeon Mobility 7500 1002:4c57

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=24414

Ian Romanick i...@freedesktop.org changed:

   What|Removed |Added

   Keywords||NEEDINFO
 CC||i...@freedesktop.org

--- Comment #16 from Ian Romanick i...@freedesktop.org 2011-01-11 17:41:38 
PST ---
Is this still reproducible with, say, Mesa 7.9.1 or Mesa 7.10?  A lot has
happened since Mesa 7.7.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Dave Airlie]

On Wed, Jan 12, 2011 at 11:36 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
 torva...@linux-foundation.org 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 more intense
 screen saver testing is coming up..

Its looking good here, I've pushed a drm-fixes branch with what Chris
sent me + a couple of i915/iommu fixes to my repo,

I'm going to run it on my laptop for a few more hours then I'll send
you a pull req, but none of the triggers I had yesterday seem to take
it down.

Dave.


                   Linus

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm intel only fixes

[Dave Airlie]

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 
pull.

Dave.

The following changes since commit 4162cf64973df51fc885825bc9ca4d055891c49f:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 (2011-01-11 
16:32:41 -0800)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Chris Wilson (25):
  drm/i915/sdvo: Defer detection of output capabilities until probing
  drm/i915/panel: Only record the backlight level when it is enabled
  drm/i915/lvds: Always use 0 to disable the pfit controller
  drm/i915: Use the mappable sizes determined by GTT for consistency.
  drm/i915: Workaround erratum on i830 for TAIL pointer within last 2 
cachelines
  agp/intel: Flush the chipset write buffers when changing GTT base
  drm/i915: add 'reset' parameter
  drm/i915: Remove impossible test
  drm/i915: Enforce write ordering through the GTT
  drm/i915: Handle ringbuffer stalls when flushing
  drm/i915: Mask USER interrupts on gen6 (until required)
  drm/i915/debugfs: Show the per-ring IMR
  drm/i915/ringbuffer: Simplify the ring irq refcounting
  drm/i915: Make the ring IMR handling private
  drm/i915: Propagate error from flushing the ring
  drm/i915: Include TLB miss overhead for computing WM
  drm/i915: Record the error batchbuffer on each ring
  drm/i915/gtt: Unmap the PCI pages after unbinding them from the GTT
  drm/i915: Periodically flush the active lists and requests
  drm/i915: Record AGP memory type upon error
  drm/i915/debugfs: Show all objects in the gtt
  drm/i915/execbuffer: Correctly clear the current object list upon EFAULT
  drm/i915/evict: Ensure we completely cleanup on failure
  drm/i915: If we hit OOM when allocating GTT pages, clear the aperture
  drm/i915/execbuffer: Reorder binding of objects to favour restrictions

Dave Airlie (3):
  Merge branch 'drm-intel-fixes' of 
ssh://master.kernel.org/.../ickle/drm-intel
  i915/gtt: fix ordering issues with status setup and DMAR
  i915/gtt: fix ordering causing DMAR errors on object teardown.

David Müller (1):
  drm/i915/crt: Check for a analog monitor in case of DVI-I

Jesse Barnes (9):
  drm/i915: check eDP encoder correctly when setting modes
  drm/i915: make DP training try a little harder
  drm/i915: support overclocking on Sandy Bridge
  drm/i915: support low power watermarks on Ironlake
  drm/i915: avoid reading non-existent PLL reg on Ironlake+
  drm/i915: re-enable rc6 support for Ironlake+
  drm/i915: fix rc6 enabling around suspend/resume
  drm/i915: cleanup rc6 code
  drm/i915: detect  report PCH display error interrupts

Yuanhan Liu (2):
  drm/i915: fix calculation of eDP signal levels on Sandybridge
  drm/i915: fix the wrong latency value while computing wm0

 drivers/char/agp/intel-agp.h   |2 +
 drivers/char/agp/intel-gtt.c   |   17 +-
 drivers/gpu/drm/i915/i915_debugfs.c|   87 +-
 drivers/gpu/drm/i915/i915_dma.c|8 -
 drivers/gpu/drm/i915/i915_drv.c|9 +
 drivers/gpu/drm/i915/i915_drv.h|   24 +-
 drivers/gpu/drm/i915/i915_gem.c|  156 +++---
 drivers/gpu/drm/i915/i915_gem_evict.c  |9 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  119 +---
 drivers/gpu/drm/i915/i915_gem_gtt.c|   10 +-
 drivers/gpu/drm/i915/i915_irq.c|  269 +++---
 drivers/gpu/drm/i915/i915_reg.h|   95 ++-
 drivers/gpu/drm/i915/i915_suspend.c|8 +-
 drivers/gpu/drm/i915/intel_crt.c   |   30 ++-
 drivers/gpu/drm/i915/intel_display.c   |  434 
 drivers/gpu/drm/i915/intel_dp.c|   50 +++-
 drivers/gpu/drm/i915/intel_drv.h   |3 +
 drivers/gpu/drm/i915/intel_fb.c|   20 +-
 drivers/gpu/drm/i915/intel_lvds.c  |   14 +-
 drivers/gpu/drm/i915/intel_panel.c |   31 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c|  255 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|   36 ++-
 drivers/gpu/drm/i915/intel_sdvo.c  |   33 +--
 23 files changed, 1082 insertions(+), 637 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 33011] New: HDMI-A-1 Does not work if disconnected at power-up (But claims it does)

[bugzilla-daemon]

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)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: russ.d...@gmail.com


I have an ATI Mobility Radeon X1600 (ChipID = 0x71c5). It has four outputs,
VGA-1, LVDS-1, HDMI-A-1, and SVIDEO-1.

I'm running 2.6.37 final (Ubuntu 2.6.37-12.26) and the Ubuntu xorg edgers
1:6.13.99+git20110110.0e432dff-0ubuntu0sarvatt version of
xserver-xorg-video-ati. I'm pretty sure this has something to do with a display
being plugged into VGA-1 as well.

xrandr --prop
Screen 0: minimum 320 x 200, current 3840 x 1350, maximum 8192 x 8192
VGA-0 connected 1920x1200+0+150 (normal left inverted right x axis y axis)
550mm x 340mm
EDID:
00000469a42664070200
1e140103683722782acbd0a35a49a024
135054bfef00714f0101814081809500
b300d1c00101283c80a070b023403020
36002654211a00ff0041374c
4d54463133323936340a00fd0032
4b1e5511000a20202020202000fc
0041535553205657323636480a200054
load detection: 1 (0x0001)range:  (0,1)
   1920x1200  60.0*+
   1920x1080  60.0  
   1680x1050  60.0  
   1280x1024  75.0 60.0  
   1440x900   59.9  
   1280x960   60.0  
   1152x864   75.0  
   1024x768   75.1 70.1 60.0  
   832x62474.6  
   800x60072.2 75.0 60.3 56.2  
   640x48072.8 75.0 66.7 60.0  
   720x40070.1  
LVDS connected (normal left inverted right x axis y axis)
EDID:
00004ca34635
00100103802115780a87f594574f8c27
2750540001010101010101010101
010101010101442f90c4601a0f401858
13004bcf1019000f
003cd20264fe0053
414d53554e470a202020202000fe
004c544e31353450342d4c30310a007f
scaling mode:Full
supported: None Full Center   Full aspect 
   1680x1050  60.6 +
   1400x1050  60.0  
   1280x1024  59.9  
   1440x900   59.9  
   1280x960   59.9  
   1280x854   59.9  
   1280x800   59.8  
   1280x720   59.9  
   1152x768   59.8  
   1024x768   59.9  
   800x60059.9  
   848x48059.7  
   720x48059.7  
   640x48059.4  
S-video disconnected (normal left inverted right x axis y axis)
tv standard:ntsc
supported: ntsc pal  pal-mpal-60  
   ntsc-j   scart-palpal-cn   secam   
load detection: 1 (0x0001)range:  (0,1)
HDMI-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis)
550mm x 340mm
EDID:
00000469a42660070200
1e140103803722782acbd0a35a49a024
135054bfef00714f0101814081809500
b30001010101283c80a070b023403020
36002654211a00ff0041374c
4d54463133323936300a00fd0032
4b1e5511000a20202020202000fc
0041535553205657323636480a2000d3
underscan vborder: 0 (0x)range:  (0,128)
underscan hborder: 0 (0x)range:  (0,128)
underscan:auto
supported: off  on   auto
coherent: 1 (0x0001)range:  (0,1)
   1920x1200  60.0*+
   1680x1050  60.0  
   1280x1024  75.0 60.0  
   1440x900   59.9  
   1280x960   60.0  
   1152x864   75.0  
   1024x768   75.1 70.1 60.0  
   832x62474.6  
   800x60072.2 75.0 60.3 56.2  
   640x48072.8 75.0 66.7 60.0  
   720x40070.1  


When I plug my laptop into the docking station which the monitor is plugged
into, I get:

[ 94924.709] (II) RADEON(0): EDID vendor SEC, prod id 13638
[ 94924.709] (II) RADEON(0): Printing DDC gathered Modelines:
[ 94924.709] (II) RADEON(0): Modeline 1680x1050x0.0  121.00  1680 1704 1792
1876  1050 1051 1054 1065 -hsync -vsync (64.5 kHz)
[ 94926.272] (II) RADEON(0): EDID vendor SEC, prod id 13638
[ 94926.272] (II) RADEON(0): Printing DDC gathered Modelines:
[ 94926.272] (II) RADEON(0): Modeline 1680x1050x0.0  121.00  1680 1704 1792
1876  1050 1051 1054 1065 -hsync -vsync (64.5 kHz)
[ 94926.537] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840
[ 94926.749] (II) RADEON(0): VRAM usage limit set to 213120K

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[Bug 33011] HDMI-A-1 Does not work if disconnected at power-up (But claims it does)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=33011

--- Comment #1 from Alex Deucher ag...@yahoo.com 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 the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel