Re: GPU lockup CP stall for more than 10000msec on latest vanilla git
On 2012.12.22 at 20:46 -0500, Alex Deucher wrote: > On Mon, Dec 17, 2012 at 5:25 PM, Markus Trippelsdorf > wrote: > > On 2012.12.17 at 17:00 -0500, Alex Deucher wrote: > >> On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf > >> wrote: > >> > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: > >> >> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf > >> >> wrote: > >> >> > As soon as I open the following website: > >> >> > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html > >> >> > > >> >> > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable: > >> >> > >> >> Is this a regression? Most likely a 3D driver bug unless you are only > >> >> seeing it with specific kernels. What browser are you using and do > >> >> you have hw accelerated webgl, etc. enabled? If so, what version of > >> >> mesa are you using? > >> > > >> > This is a regression, because it is caused by yesterdays merge of > >> > drm-next by Linus. IOW I only see this bug when running a > >> > v3.7-9432-g9360b53 kernel. > >> > >> Can you bisect? I'm guessing it may be related to the new DMA rings. > >> Possibly: > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 > > > > Yes, the commit above causes the issue. > > > > Does booting with radeon.wb=0 fix the issue? Please make sure your > kernel has this patch: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246 My kernel has this patch and radeon.wb=0 doesn't help. It still freezes the machine as soon as you scroll on a website with many big images. -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GPU lockup CP stall for more than 10000msec on latest vanilla git
On 2012.12.23 at 10:09 +, Andy Furniss wrote: > Markus Trippelsdorf wrote: > > >> Does booting with radeon.wb=0 fix the issue? Please make sure your > >> kernel has this patch: > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246 > > > > My kernel has this patch and radeon.wb=0 doesn't help. > > I think that should be no_wb=1 Yes, you're right. But even with radeon.no_wb=1 it still hangs: ... Dec 23 11:15:02 x4 kernel: radeon :01:05.0: WB disabled Dec 23 11:15:02 x4 kernel: radeon :01:05.0: fence driver on ring 0 use gpu addr 0xa004 and cpu addr 0x8802163ad004 Dec 23 11:15:02 x4 kernel: radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8802163adc0c Dec 23 11:15:02 x4 kernel: radeon :01:05.0: setting latency timer to 64 ... Dec 23 11:16:04 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more than 1msec Dec 23 11:16:04 x4 kernel: radeon :01:05.0: GPU lockup (waiting for 0x089c last fence id 0x089b) Dec 23 11:16:04 x4 kernel: radeon :01:05.0: Saved 217 dwords of commands on ring 0. Dec 23 11:16:04 x4 kernel: radeon :01:05.0: GPU softreset Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008010_GRBM_STATUS=0xA000B030 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008014_GRBM_STATUS2=0x0003 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_000E50_SRBM_STATUS=0x20005040 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x0002 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0xD086 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008680_CP_STAT = 0x80098645 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x7FEE Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x0001 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008010_GRBM_STATUS=0xA000B030 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008014_GRBM_STATUS2=0x0003 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_000E50_SRBM_STATUS=0x2000C040 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008680_CP_STAT = 0x8010 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: GPU reset succeeded, trying to resume Dec 23 11:16:04 x4 kernel: [drm] PCIE GART of 512M enabled (table at 0xC004). Dec 23 11:16:04 x4 kernel: radeon :01:05.0: WB disabled Dec 23 11:16:04 x4 kernel: radeon :01:05.0: fence driver on ring 0 use gpu addr 0xa004 and cpu addr 0x8802163ad004 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8802163adc0c Dec 23 11:16:04 x4 kernel: radeon :01:05.0: setting latency timer to 64 Dec 23 11:16:04 x4 kernel: [drm] ring test on 0 succeeded in 1 usecs Dec 23 11:16:05 x4 kernel: [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) Dec 23 11:16:05 x4 kernel: [drm:r600_resume] *ERROR* r600 startup failed on resume Dec 23 11:16:09 x4 kernel: SysRq : Emergency Sync Dec 23 11:16:09 x4 kernel: Emergency Sync complete Dec 23 11:16:15 x4 kernel: SysRq : Emergency Remount R/O Dec 23 11:16:15 x4 kernel: EXT4-fs (sdb2): re-mounted. Opts: (null) -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GPU lockup CP stall for more than 10000msec on latest vanilla git
Markus Trippelsdorf wrote: Does booting with radeon.wb=0 fix the issue? Please make sure your kernel has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246 My kernel has this patch and radeon.wb=0 doesn't help. I think that should be no_wb=1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58666] rv670 + llvm = errors.
https://bugs.freedesktop.org/show_bug.cgi?id=58666 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- 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: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 07:42:16PM -0500, Alex Deucher wrote:
> Does booting with radeon.wb=0 help?
Right, this param specification somehow didn't work here:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.wb=0
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.wb=0
[ … ]
[6.910104] radeon: `0' invalid for parameter `wb'
[ … ]
[ 28.191072] radeon: `0' invalid for parameter `wb'
although the whole driver blubber didn't appear on the console fterwards
aso something got turned off allright.
Then, I went and tried "radeon.no_wb" where the driver blubber appeared
but AGP writeback was still enabled:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.no_wb
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.no_wb
[ … ]
[6.382636] [drm] radeon kernel modesetting enabled.
[6.384915] radeon :02:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[6.384981] radeon :02:00.0: GTT: 512M 0x2000 -
0x3FFF
[6.388137] [drm] radeon: 512M of VRAM memory ready
[6.388181] [drm] radeon: 512M of GTT memory ready.
[6.388509] radeon :02:00.0: irq 42 for MSI/MSI-X
[6.388570] radeon :02:00.0: radeon: using MSI.
[6.388705] [drm] radeon: irq initialized.
[6.567811] radeon :02:00.0: WB enabled
^^
[6.567856] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x8802243e5c00
[6.567922] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x8802243e5c0c
[6.601247] [drm] Radeon Display Connectors
[6.602427] [drm] radeon: power management initialized
[6.722544] fbcon: radeondrmfb (fb0) is primary device
[6.945065] radeon :02:00.0: fb0: radeondrmfb frame buffer device
[6.945100] radeon :02:00.0: registered panic notifier
[6.945159] [drm] Initialized radeon 2.27.0 20080528 for :02:00.0 on
minor 0
At this point, I got tired of this experimenting and went and took the
big hammer :-):
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 49b06590001e..00214312db23 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -307,6 +307,11 @@ int radeon_wb_init(struct radeon_device *rdev)
rdev->wb.use_event = true;
}
+ if (rdev->wb.enabled) {
+ pr_err("%s: disable the goddam WB: radeon_no_wb: %d\n",
__func__, radeon_no_wb);
+ rdev->wb.enabled = false;
+ }
+
dev_info(rdev->dev, "WB %sabled\n", rdev->wb.enabled ? "en" : "dis");
return 0;
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1+ root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.no_wb no_wb
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1+
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.no_wb no_wb
[6.562905] [drm] radeon kernel modesetting enabled.
[6.565106] radeon :02:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[6.565172] radeon :02:00.0: GTT: 512M 0x2000 -
0x3FFF
[6.567696] [drm] radeon: 512M of VRAM memory ready
[6.567742] [drm] radeon: 512M of GTT memory ready.
[6.568068] radeon :02:00.0: irq 42 for MSI/MSI-X
[6.568130] radeon :02:00.0: radeon: using MSI.
[6.568269] [drm] radeon: irq initialized.
[6.684920] radeon_wb_init: disable the goddam WB: radeon_no_wb: 0
[6.684967] radeon :02:00.0: WB disabled
^^^
[6.685011] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x880221ea3c00
[6.685077] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x880221ea3c0c
[6.722367] [drm] Radeon Display Connectors
[6.723548] [drm] radeon: power management initialized
[6.843185] fbcon: radeondrmfb (fb0) is primary device
[7.066368] radeon :02:00.0: fb0: radeondrmfb frame buffer device
[7.066402] radeon :02:00.0: registered panic notifier
[7.066462] [drm] Initialized radeon 2.27.0 20080528 for :02:00.0 on
minor 0
Ok, I hope I turned off the proper WB thing (I'm assuming you meant the
radeon_no_wb param
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Borislav Petkov wrote: [ 28.191072] radeon: `0' invalid for parameter `wb' although the whole driver blubber didn't appear on the console fterwards aso something got turned off allright. Then, I went and tried "radeon.no_wb" where the driver blubber appeared but AGP writeback was still enabled: no_wb=1 should work. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote: > no_wb=1 should work. Yeah, maybe all those radeon and other GPU module parameters' syntax should be documented somewhere - Documentation/kernel-parameters.txt for example, or a GPU-specific file, whatever - so that we can save us all the time and confusion. Provided this hasn't happened yet, of course. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Borislav Petkov wrote: On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote: no_wb=1 should work. Yeah, maybe all those radeon and other GPU module parameters' syntax should be documented somewhere - Documentation/kernel-parameters.txt for example, or a GPU-specific file, whatever - so that we can save us all the time and confusion. Provided this hasn't happened yet, of course. modinfo radeon will give a list assuming you use modules, I think all of them need =. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote: > modinfo radeon > > will give a list assuming you use modules, I think all of them need =. Yep, that is one way of getting that info, thanks. I always go and look at Documentation/kernel-parameters.txt and forget about modinfo. As you say 'radeon' needs to be module but since this is the case with the distros, the majority of Linux installations out there have it this way so we're fine. Btw, there's a typo in the param list, if anyone wants to write a patch for it :-): parm: lockup_timeout:GPU lockup timeout in ms (defaul 1 = 10 seconds, 0 = disable) (int) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 2012.12.23 at 12:31 +0100, Borislav Petkov wrote: > On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote: > > modinfo radeon > > > > will give a list assuming you use modules, I think all of them need =. > > Yep, that is one way of getting that info, thanks. I always go and look > at Documentation/kernel-parameters.txt and forget about modinfo. > > As you say 'radeon' needs to be module but since this is the case with > the distros, the majority of Linux installations out there have it this > way so we're fine. (If you don't use modules: git grep MODULE_PARM_DESC -- drivers/gpu/drm/radeon/ ) You may have hit the same issue as I, see: http://thread.gmane.org/gmane.comp.video.dri.devel/78328 Reverting commit 2d6cc729 fixes the problem for me, setting radeon.no_wb=1 doesn't help. -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, 2012-12-23 at 11:01 +, Andy Furniss wrote: > Borislav Petkov wrote: > > > [ 28.191072] radeon: `0' invalid for parameter `wb' > > > > although the whole driver blubber didn't appear on the console fterwards > > aso something got turned off allright. > > > > Then, I went and tried "radeon.no_wb" where the driver blubber appeared > > but AGP writeback was still enabled: > > no_wb=1 should work. Perhaps some of the module_param_named(,,int,) should be bool Also, are all of the various permissions appropriate? $ git grep module_param_named drivers/gpu/drm/radeon/ drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(no_wb, radeon_no_wb, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(modeset, radeon_modeset, int, 0400); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(dynclks, radeon_dynclks, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(r4xx_atom, radeon_r4xx_atom, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(vramlimit, radeon_vram_limit, int, 0600); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(agpmode, radeon_agpmode, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(gartsize, radeon_gart_size, int, 0600); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(benchmark, radeon_benchmarking, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(test, radeon_testing, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(connector_table, radeon_connector_table, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(tv, radeon_tv, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(audio, radeon_audio, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(disp_priority, radeon_disp_priority, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(hw_i2c, radeon_hw_i2c, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(pcie_gen2, radeon_pcie_gen2, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(msi, radeon_msi, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(lockup_timeout, radeon_lockup_timeout, int, 0444); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 12:51:33PM +0100, Markus Trippelsdorf wrote: > (If you don't use modules: git grep MODULE_PARM_DESC -- > drivers/gpu/drm/radeon/ ) Yeah. > You may have hit the same issue as I, see: > http://thread.gmane.org/gmane.comp.video.dri.devel/78328 Yes, it very much looks like it. That same page kills the machine here too. Maybe the GPU gets scared from the graphic nature of those images and gives up. :-D Although the box is not completely dead - I can login to a console and save dmesg before rebooting. And this bug becomes funnier and funnier - Alex, you might want to add that webpage to your testsuite :-). > Reverting commit 2d6cc729 fixes the problem for me, setting > radeon.no_wb=1 doesn't help. Right, let me try that and report back. Good job Markus, thanks! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote: > Right, let me try that and report back. Yep, looks like reverting the above commit fixes it - the boston.com website loads just fine. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] radeon drm-next-3.8
2012/12/8 : > Alex Deucher (6): > drm/radeon/dce3.2: add registers for ELD handling > drm/radeon/dce4/5: add registers for ELD handling Sorry, I can't reply to the any of above patches. Alex: can we also get definition of (1 << 20) bit for AZ_HOT_PLUG_CONTROL? Just my curiosity :) -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #2 from Bryan Quigley --- My kernel build does have that patch. Unfortunately, I am having trouble bisecting because something that appears unrelated makes my system fail to boot. That boot failure already been fixed in more recent builds thought :/. -- 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
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #3 from Alex Deucher --- Looks like this is probably a duplicate of this issue: http://lists.freedesktop.org/archives/dri-devel/2012-December/032547.html See if reverting commit 2d6cc729 fixes the problem. -- 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
[PATCH] drm/radeon/6xx: disable use of the DMA ring for ttm bo moves
From: Alex Deucher
Seems to fall over in some cases with heavy memory thrashing on
6xx. Needs more investigation after the holidays, disable for
now.
Cc: Markus Trippelsdorf
Cc: Borislav Petkov
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 596bcbe..c66b92d 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -974,8 +974,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1058,8 +1058,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/6xx: disable use of the DMA ring for ttm bo moves
On Sun, Dec 23, 2012 at 01:28:25PM -0500, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > Seems to fall over in some cases with heavy memory thrashing on > 6xx. Needs more investigation after the holidays, disable for > now. > > Cc: Markus Trippelsdorf > Cc: Borislav Petkov > Signed-off-by: Alex Deucher Yep, running with the revert doesn't show any other adverse effects so the real fix can take its time, relax and enjoy the holidays :-). I'll test this one tomorrow just in case, even though it looks trivial. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #6 from Thomas Rohloff --- Created attachment 72041 --> https://bugs.freedesktop.org/attachment.cgi?id=72041&action=edit New dmesg output Never mind, I found the patch here: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=33e5467871b3007c4e6deea95b2cac38a55ff9f5 I reverted it and no crash so far (but as they are random they might still occur). On the other side the dmesg messages are still there. Uploading the new output just in case it is needed. While writing this minecraft (which I used to trigger the crashes) crashed (right before and shortly after the crash the mouse wsq in slow-motion and I thought it will crash right away). -- 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
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #5 from Thomas Rohloff --- To add some more to this bug report: Some things in Minecraft aren't rendered at all: Water, Signs, Items (on the ground), all kind of mobs (animals, monsters, ...), the selection ring around blocks and maybe more. -- 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
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #6 from Thomas Rohloff --- Whoever changed the report title: It is broken on the locked BIOS, not on the unlocked. -- 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
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #7 from Thomas Rohloff --- Crashes are still there after reverting "drm/radeon: use DMA engine for VM page table updates on cayman/TN" -- 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
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #8 from Thomas Rohloff --- But this crash was different: The image froze but the monitor didn't go into standby nor came it back with garbage. -- 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
[Bug 58658] Minecraft menu broken on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58658 --- Comment #4 from Thomas Rohloff --- Bisected mesa. This is a mesa bug caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664 Can anybody move this to the right place or do I have to re-create the report (and if so: Where) ? -- 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
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #6 from Thomas Rohloff --- Bisected mesa. This is a mesa bug caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664 Can anybody move this to the right place or do I have to re-create the report (and if so: Where) ? -- 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
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #7 from Thomas Rohloff --- Bisected mesa. This is a mesa bug caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664 Can anybody move this to the right place or do I have to re-create the report (and if so: Where) ? I also think this is a duplication of https://bugs.freedesktop.org/show_bug.cgi?id=58667 - The crashes just occur way more often (right after starting compiz) with the locked BIOS. -- 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
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #9 from Thomas Rohloff --- Bisected mesa. This is a mesa bug caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664 Can anybody move this to the right place or do I have to re-create the report (and if so: Where) ? -- 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
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #10 from Thomas Rohloff --- I was to fast with this. While the error messages in dmesg are gone it still randomly crashes, but this time the computer just froze completely. I think this bug report are in fact at least two bugs. -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #5 from smoki --- Created attachment 72047 --> https://bugs.freedesktop.org/attachment.cgi?id=72047&action=edit Myr200FrontFace Seems like i managed to fix it, but with dirty hack... see function in attachment. tcl somehow is not aware of wind inverting, and i just inverted commands, but it works that way :). This fbo test case works, fbotexture and tri-cull from mesa demos - with both swtcl and tcl. What i tested, yeah Aquaria game is no more black with fbo usage and also Supertuxkart now show icons in minimap, etc. Anyhow, maybe someone know how to make that better to be acceptible for mesa and pushed in git - i don't know better :). -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #6 from Stefan Dösinger --- I'll give the patch a try after the holidays. My I'm currently 100 miles away from my r200-equipped laptop and won't have access to it until Wednesday or Thursday. -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #7 from Rafał Mużyło --- Perhaps the message in this commit (http://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/drivers/dri/r200/r200_state.c?id=60e60bb3026a269fefe1cfd3312fdf3a7e4c595f) is of note: Tested with r300, radeon and r200 compile tested only. Though looking at the changes of attachment 72047, perhaps the other cards should be rechecked too - these changes look more like the changes made in that commit to r300, so it might not be as much of a hack as the author thought. -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #8 from Rafał Mużyło --- ...minor correction: that r300 was for the non-galium driver (that was removed awhile ago), but it seems that the logic in that commit was incorrect, so the "hack" from that attachement seems to be a logic fix and most likely *is* valid for radeon/radeon_state.c. -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #9 from smoki --- That Dänzer's commit is good, it inverts winding properly and it works good but for swtcl only. My tries to make it work but for both swtcl and tcl, and for Stefan's test case also. And it works for me both swtcl and tcl for those tests, but i am not very good at programming ;). "Fixes fgl_glxgears and progs/demos/fbotexture after pressing 'c'." Yeah that both works too "pressing 'c'" now works. Pbuffered fgl_glxgears works, but with -fbo switch - that never showing a texture on r200 :). So i've tested: fgl_glxgears, fbotexture, supertuxkart, fbo test from this bug... and also tri-cull to be sure no-fbo case work. And that all works for swtcl and tcl on rv280. -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #10 from smoki --- Created attachment 72050 --> https://bugs.freedesktop.org/attachment.cgi?id=72050&action=edit STK minimap icon He, he, i'am not programmer at all ;) but i managed to fix fogcoords, lighting and culling on rv280 with tcl this year. Happy holidays :). -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 smoki changed: What|Removed |Added Attachment #72050|text/plain |image/png mime type|| -- 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
[Bug 58696] New: Choppy video playback in VLC with R600g on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=58696 Priority: medium Bug ID: 58696 Assignee: dri-devel@lists.freedesktop.org Summary: Choppy video playback in VLC with R600g on Radeon HD 6620G Severity: normal Classification: Unclassified OS: All Reporter: runetmem...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Video playback of almost any typical 10Mbps 1080p BDRip is choppy (many dropped frames) in VLC if R600g driver is used instead of fglrx on Radeon HD 6620G GPU. Enabling/disabling composting doesn't make difference (so this issue is not duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=47776 ). Enabling/disabling "Suspend desktop effects for fullscreen windows" KWin options doesn't make difference for fullscreen playback. There is little difference between xv and OpenGL (GLX) output in VLC - xv output a little faster but gives choppy playback too. Issue is not reproducible: 1. in mplayer (SMPlayer is used) with R600g driver, 2. in Firefox (1080p VP8 playback) in Chrome (1080p H.264 playback) and in Adobe Flash 11.5 plugin (1080p H.264 too) with R600g driver. 3. in VLC with fglrx driver (hardware decoder is not enabled). Issue happen only in VLC&R600g combination. VLC always uses indirect rendering instead of direct so I check mplayer playback with disabled direct rendering and with enabled direct rendering but I doesn't notice any difference. AFAIK mplayer and VLC drops frames very differently so I check mplayer with disabled frame drop and with enabled frame drop but (again) doesn't notice any difference. So I doesn't sure what exactly is wrong in VLC&R600g combination but choppy video playback happen only in this combination for sure. In my opinion issues most likely is relevant only for APU hardware. Video sample used for testing: http://www.multiupload.nl/56CCVTW42H (most noticeable slowdown happen since 00:32). Software: Linux 3.8rc1 libdrm 2.4.40+git20121123.171666e4 Mesa 9.1~git20121222.a585b8f3 xserver-xorg-video-radeon 7.0.99+git20121207.793e1b0e Xserver 1.13.0.902+git20121207 VLC 2.0.5 (default settings tested too - no difference) mplayer 1.0~rc4.dfsg1+svn34540 Kubuntu 12.10 x86_64, Xorg Edgers PPA enabled. Hardware: A8-3500M with Radeon HD 6620G. -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #11 from Rafał Mużyło --- Created attachment 72051 --> https://bugs.freedesktop.org/attachment.cgi?id=72051&action=edit attachment 72047 as patch for r200/radeon @comment 9: your own attachment says it was not. Anyway, attachment 72047 translated into a patch. 'cull_face = (mode == GL_CW) ? R200_FFACE_CULL_CW : R200_FFACE_CULL_CCW' is bit of a mouthful, but atm. I've got not idea how to turn that into proper obfuscation style of mesa sources. -- 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
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #12 from smoki --- Yeah i tried your patch and it works, thanks Raphal. Someone could pushed it in git if it's in good looking now ;). -- 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
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #4 from Bryan Quigley --- Reverting patch 2d6cc729 does indeed fix the problem. -- 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 0/6] Common Display Framework-T
Hi Laurent, On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart wrote: > Hi Tomi, > > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote: >> Hi, >> >> I have been testing Common Display Framework on OMAP, and making changes >> that I've discussed in the posts I've sent in reply to the CDF series from >> Laurent. While my CDF code is rather hacky and not at all ready, I wanted >> to post the code for comments and also as a reference code to my posts. >> >> So here is CDF-T (Tomi-edition =). > > We've discussed your approach extensively face-to-face today so I won't review > the patches in detail, but I will instead summarize our discussion to make > sure we understood each other (and let other developers jump in). > > For the purpose of this discussion the term "display controller driver" (or > just "display controller") refer to both the low-level driver layer that > communicates directly with the display controller hardware, and to the higher- > level driver layer that implements and exposes the userspace API (FBDEV, KMS > and/or V4L). Those layers can be implemented in multiple kernel modules (such > as in the OMAP DSS case, with omapdss for the low-level layer and omapdrm, > omapfb and omapvout for the API-level layer) or a single kernel module. > > Control model > - > > The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control- > model.png shows the CDF control model. > > The panel object depicted on the figure doesn't need to be a panel in the > stricter sense but could be any chain of off-SoC (both on-board or off-board) > display entities. It however helps thinking about it as a panel and doesn't > hurt the model. > > The panel is controlled through abstract control requests. Those requests are > used to retrieve panel information (such as the physical size, the supported > video modes, EDID information, ...), set the panel configuration (such as the > active video timings) or control the panel operation state (enabling/disabling > the panel, controlling panel blanking and power management, ...). They are > exposed by the panel using function pointers, and called by other kernel > components in response to userspace requests (through the FBDEV, KMS or V4L2 > APIs) or in-kernel events (for instance hotplug notifications). > > In response to the control requests the panel driver will communicate with the > panel through the panel control bus (I2C, SPI, DBI, DSI, GPIO, ..., not shown > on the figure) and will control the video stream it receives on its input. > > The panel is connected at the hardware level to a video source (shown as a > green hashed rectangle) that provides it with a video stream. The video stream > flows from the video source to the panel and is directly controlled by its > source, as shown by the green arrow from the display controller to the video > stream. The video source exposes stream control operations as function > pointers that are used by the panel to control the video stream, as shown by > the green arrow from the panel to the video source. > > The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control- > model-2.png shows the call flow across entities when the panel is a pipeline > made of more than a single entity. In this case the SoC (on the left of the > dashed line) outputs a video stream on a DSI bus connected to a DSI to LVDS > transmitter. The output of the DSI to LVDS transmitter is connected to an LVDS > panel (or, more accurately, an LVDS panel module made of an LVDS panel > controller and a panel). > > The transmitter and panel module are seen by the display controller and > userspace API implementations as a single entity that exposes control request > operations and controls its input video stream. When a control request is > performed (outermost green arrow) the DSI to LVDS transmitter will propagate > it to the panel, possibly mangling the input parameters or the response. For > panel operation state control requests the last entity in the pipeline will > likely want to control the video stream it receives on its input. The video > stream control calls will be propagated from right to left as shown by the red > arrows. > > Every entity in the call stack can communicate with its hardware device > through the corresponding control bus, and/or control the video stream it > receives on its input. > > This model allows filtering out modes and timings supported by the panel but > unsupported by the transmitter and mangling the modes and timings according to > the transmitter limitations. It has no complexity drawback for simple devices, > as the corresponding drivers can just forward the calls directly. Similar use > cases could exist for other control operations than mode and information > retrieval. > > Discovery > - > > Before being able to issue control requests, panel devices need to be > discovered and associated with the connected display controller(s). > > Panels and display controllers are cross-dependen
[Bug 58667] New: Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 Priority: medium Bug ID: 58667 Assignee: dri-devel at lists.freedesktop.org Summary: Random crashes on CAYMAN Severity: normal Classification: Unclassified OS: All Reporter: v10lator at myway.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI This is with newest mesa from git with kernel 3.8-rc1 (+ this patch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8&id=668bbc81baf0f34df832d8aca5c7d5e19a493c68 ) The screen first freezes (mouse still movable, keyboard not responding, not even to MagSysRQ), then the monitor goes off (standby) and back on with only garbage on the screen. Not sure if this has anything to do with it (but it should get fixed anyway) but dmesg gets spammed with this: [ 533.928472] radeon :03:00.0: GPU fault detected: 146 0x00335514 [ 533.928477] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 533.928483] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x where the address isn't always the same, example: [ 533.928374] radeon :03:00.0: GPU fault detected: 146 0x0033ed14 [ 533.928379] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 533.928385] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/54b46f87/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #1 from Thomas Rohloff --- Created attachment 72006 --> https://bugs.freedesktop.org/attachment.cgi?id=72006&action=edit Full dmesg output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/df6fac42/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #2 from Alex Deucher --- Is this a regression? Does it happen with older versions of mesa or kernel? If it's a regression can you identify which component (mesa or kernel) and bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/efd9b9a0/attachment.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #3 from Alex Deucher --- Can you get the dmesg output when the lockup happens? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/d89a8e40/attachment-0001.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #3 from Alex Deucher --- May also be related to bug 58354. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/deeb9a25/attachment.html>
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #3 from Thomas Rohloff --- The thing is that I can't access dmesg after the crash. Not even SysMagRQ works. See my dmesg with the other BIOS here: https://bugs.freedesktop.org/attachment.cgi?id=72006 I have the BIOSes still lying around somewhere. Let me search real quick. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/13ad34c4/attachment.html>
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #4 from Thomas Rohloff --- Created attachment 72008 --> https://bugs.freedesktop.org/attachment.cgi?id=72008&action=edit BIOS 0 (locked shaders) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/8e7cd8ab/attachment.html>
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #5 from Thomas Rohloff --- Created attachment 72009 --> https://bugs.freedesktop.org/attachment.cgi?id=72009&action=edit BIOS 1 (unlocked shaders) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/a1e9b960/attachment.html>
[Bug 58658] Minecraft menu broken on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58658 --- Comment #3 from Thomas Rohloff --- I'm not sure if it's mesa or kernel. Yes, it was working before last update (updated mesa + kernel). I might be able to bisect later but atm my time is limited and as I don't even know what to bisect (kernel or mesa) it may take some time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/1893b740/attachment.html>
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote: > What chip is this? I think it is RV635. Here's the whole 3.8-rc1 dmesg. [0.00] Linux version 3.8.0-rc1 (boris at liondog) (gcc version 4.7.2 (Debian 4.7.2-4) ) #13 SMP PREEMPT Sat Dec 22 11:48:54 CET 2012 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel hpet=force [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcffe] usable [0.00] BIOS-e820: [mem 0xcfff-0xcfff2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfff3000-0xcfff] ACPI data [0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf000-0xf7ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022fff] usable [0.00] debug: ignoring loglevel setting. [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.3 present. [0.00] DMI:/M57SLI-S4, BIOS FF 01/24/2008 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x23 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C7FFF write-protect [0.00] C8000-E uncachable [0.00] F-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask C000 write-back [0.00] 2 base C000 mask F000 write-back [0.00] 3 base 0001 mask write-back [0.00] 4 base 0002 mask E000 write-back [0.00] 5 base 00022000 mask F000 write-back [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00023000 aka 8960M [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: update [mem 0xd000-0x] usable ==> reserved [0.00] e820: last_pfn = 0xcfff0 max_arch_pfn = 0x4 [0.00] initial memory mapped: [mem 0x-0x1fff] [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0xcffe] [0.00] [mem 0x-0xbfff] page 1G [0.00] [mem 0xc000-0xcfdf] page 2M [0.00] [mem 0xcfe0-0xcffe] page 4k [0.00] kernel direct mapping tables up to 0xcffe @ [mem 0x1fffd000-0x1fff] [0.00] init_memory_mapping: [mem 0x1-0x22fff] [0.00] [mem 0x1-0x1] page 1G [0.00] [mem 0x2-0x22fff] page 2M [0.00] kernel direct mapping tables up to 0x22fff @ [mem 0xcffee000-0xcffe] [0.00] ACPI: RSDP 000f6620 00014 (v00 GBT ) [0.00] ACPI: RSDT cfff3000 00038 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: FACP cfff3040 00074 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: DSDT cfff30c0 04C8E (v01 GBTNVDAACPI 1000 MSFT 010C) [0.00] ACPI: FACS cfff 00040 [0.00] ACPI: SSDT cfff7e40 004CE (v01 PTLTD POWERNOW 0001 LTP 0001) [0.00] ACPI: HPET cfff8340 00038 (v01 GBTNVDAACPI 42302E31 NVDA 0098) [0.00] ACPI: MCFG cfff8380 0003C (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: APIC cfff7d80 00098 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: Local APIC address 0xfee0 [0.00] [ea00-ea0008bf] PMD -> [88022760-88022f5f] on node 0 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x22fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009efff] [0.00] node 0: [mem 0x0010-0xcffe] [0.00] node 0: [mem 0x1-0x22fff] [0.00] On node 0 totalpages: 2097023 [0.00] DMA
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #3 from Thomas Rohloff --- I'm not sure if it's mesa or kernel. Yes, it was working before last update (updated mesa + kernel). I might be able to bisect later but atm my time is limited and as I don't even know what to bisect (kernel or mesa) it may take some time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/fba28376/attachment.html>
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #4 from Thomas Rohloff --- Also I'm not sure about the dmesg output from here: https://bugs.freedesktop.org/show_bug.cgi?id=58667 - It might be connected. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/956588cc/attachment.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #4 from Alexandre Demers --- Hitting some other bug right now with bug 58655. I'll apply the proposed patch for the other bug and I'll see what I get then. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/912869c2/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #4 from Thomas Rohloff ---
!Is this a regression? Does it happen with older versions of mesa or kernel?!
Not that I know about.
"May also be related to bug 58354."
Do you have the path noted there ("drm/radeon: use DMA engine for VM page table
updates on cayman/TN") ? I would loce to try to revert this patch and test it,
but I'm unable to google it.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/b9977a91/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #5 from Thomas Rohloff ---
I should really read before I click save, sorry. Here again:
"Is this a regression? Does it happen with older versions of mesa or kernel?"
Not that I know about.
"May also be related to bug 58354."
Do you have a link to the patch noted there ("drm/radeon: use DMA engine for VM
page table updates on cayman/TN") ? I would love to try to revert this patch
and test it, but I'm unable to google it.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/6602d141/attachment.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #5 from Alex Deucher --- Created attachment 72013 --> https://bugs.freedesktop.org/attachment.cgi?id=72013&action=edit possible fix Does this patch fix the issue? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/86e5d09e/attachment-0001.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #6 from Alexandre Demers --- Created attachment 72014 --> https://bugs.freedesktop.org/attachment.cgi?id=72014&action=edit dmesg after lockup This is the salvaged dmesg retrieved with the help of a ssh connection. Sadly, I don't think there is anything useful in there. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/3c8fff12/attachment.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #7 from Alexandre Demers --- Would it help if I was increasing the debug level? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/1e196cbc/attachment.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #8 from Alexandre Demers --- (In reply to comment #5) > Created attachment 72013 [details] [review] > possible fix > > Does this patch fix the issue? Testing right away. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/d7c6f7f6/attachment.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
or the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/7950bee0/attachment-0001.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
4 > [ 6223.054980] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 6223.054982] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x > ... > > I'm sure it is a different bug, can you confirm? dmesg.log stops to be > populated when X/Gnome start, but typing dmesg in a terminal outputs tons of > the reported messages. Should I open a new bug for it or has it been already > reported? Found something similar, it looks bug 58667. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/05f064a7/attachment.html>
GPU lockup CP stall for more than 10000msec on latest vanilla git
On 2012.12.22 at 20:46 -0500, Alex Deucher wrote: > On Mon, Dec 17, 2012 at 5:25 PM, Markus Trippelsdorf > wrote: > > On 2012.12.17 at 17:00 -0500, Alex Deucher wrote: > >> On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf > >> wrote: > >> > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: > >> >> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf > >> >> wrote: > >> >> > As soon as I open the following website: > >> >> > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html > >> >> > > >> >> > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable: > >> >> > >> >> Is this a regression? Most likely a 3D driver bug unless you are only > >> >> seeing it with specific kernels. What browser are you using and do > >> >> you have hw accelerated webgl, etc. enabled? If so, what version of > >> >> mesa are you using? > >> > > >> > This is a regression, because it is caused by yesterdays merge of > >> > drm-next by Linus. IOW I only see this bug when running a > >> > v3.7-9432-g9360b53 kernel. > >> > >> Can you bisect? I'm guessing it may be related to the new DMA rings. > >> Possibly: > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 > > > > Yes, the commit above causes the issue. > > > > Does booting with radeon.wb=0 fix the issue? Please make sure your > kernel has this patch: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246 My kernel has this patch and radeon.wb=0 doesn't help. It still freezes the machine as soon as you scroll on a website with many big images. -- Markus
GPU lockup CP stall for more than 10000msec on latest vanilla git
On 2012.12.23 at 10:09 +, Andy Furniss wrote: > Markus Trippelsdorf wrote: > > >> Does booting with radeon.wb=0 fix the issue? Please make sure your > >> kernel has this patch: > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246 > > > > My kernel has this patch and radeon.wb=0 doesn't help. > > I think that should be no_wb=1 Yes, you're right. But even with radeon.no_wb=1 it still hangs: ... Dec 23 11:15:02 x4 kernel: radeon :01:05.0: WB disabled Dec 23 11:15:02 x4 kernel: radeon :01:05.0: fence driver on ring 0 use gpu addr 0xa004 and cpu addr 0x8802163ad004 Dec 23 11:15:02 x4 kernel: radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8802163adc0c Dec 23 11:15:02 x4 kernel: radeon :01:05.0: setting latency timer to 64 ... Dec 23 11:16:04 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more than 1msec Dec 23 11:16:04 x4 kernel: radeon :01:05.0: GPU lockup (waiting for 0x089c last fence id 0x089b) Dec 23 11:16:04 x4 kernel: radeon :01:05.0: Saved 217 dwords of commands on ring 0. Dec 23 11:16:04 x4 kernel: radeon :01:05.0: GPU softreset Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008010_GRBM_STATUS=0xA000B030 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008014_GRBM_STATUS2=0x0003 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_000E50_SRBM_STATUS=0x20005040 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x0002 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0xD086 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008680_CP_STAT = 0x80098645 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x7FEE Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x0001 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008010_GRBM_STATUS=0xA000B030 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008014_GRBM_STATUS2=0x0003 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_000E50_SRBM_STATUS=0x2000C040 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x Dec 23 11:16:04 x4 kernel: radeon :01:05.0: R_008680_CP_STAT = 0x8010 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: GPU reset succeeded, trying to resume Dec 23 11:16:04 x4 kernel: [drm] PCIE GART of 512M enabled (table at 0xC004). Dec 23 11:16:04 x4 kernel: radeon :01:05.0: WB disabled Dec 23 11:16:04 x4 kernel: radeon :01:05.0: fence driver on ring 0 use gpu addr 0xa004 and cpu addr 0x8802163ad004 Dec 23 11:16:04 x4 kernel: radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8802163adc0c Dec 23 11:16:04 x4 kernel: radeon :01:05.0: setting latency timer to 64 Dec 23 11:16:04 x4 kernel: [drm] ring test on 0 succeeded in 1 usecs Dec 23 11:16:05 x4 kernel: [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) Dec 23 11:16:05 x4 kernel: [drm:r600_resume] *ERROR* r600 startup failed on resume Dec 23 11:16:09 x4 kernel: SysRq : Emergency Sync Dec 23 11:16:09 x4 kernel: Emergency Sync complete Dec 23 11:16:15 x4 kernel: SysRq : Emergency Remount R/O Dec 23 11:16:15 x4 kernel: EXT4-fs (sdb2): re-mounted. Opts: (null) -- Markus
GPU lockup CP stall for more than 10000msec on latest vanilla git
Markus Trippelsdorf wrote: >> Does booting with radeon.wb=0 fix the issue? Please make sure your >> kernel has this patch: >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=86a1881d08f65a42c17071a59c0088dbe2870246 > > My kernel has this patch and radeon.wb=0 doesn't help. I think that should be no_wb=1
[Bug 58666] rv670 + llvm = errors.
https://bugs.freedesktop.org/show_bug.cgi?id=58666 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/d68bd572/attachment-0001.html>
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 07:42:16PM -0500, Alex Deucher wrote:
> Does booting with radeon.wb=0 help?
Right, this param specification somehow didn't work here:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.wb=0
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.wb=0
[ ? ]
[6.910104] radeon: `0' invalid for parameter `wb'
[ ? ]
[ 28.191072] radeon: `0' invalid for parameter `wb'
although the whole driver blubber didn't appear on the console fterwards
aso something got turned off allright.
Then, I went and tried "radeon.no_wb" where the driver blubber appeared
but AGP writeback was still enabled:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.no_wb
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.no_wb
[ ? ]
[6.382636] [drm] radeon kernel modesetting enabled.
[6.384915] radeon :02:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[6.384981] radeon :02:00.0: GTT: 512M 0x2000 -
0x3FFF
[6.388137] [drm] radeon: 512M of VRAM memory ready
[6.388181] [drm] radeon: 512M of GTT memory ready.
[6.388509] radeon :02:00.0: irq 42 for MSI/MSI-X
[6.388570] radeon :02:00.0: radeon: using MSI.
[6.388705] [drm] radeon: irq initialized.
[6.567811] radeon :02:00.0: WB enabled
^^
[6.567856] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x8802243e5c00
[6.567922] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x8802243e5c0c
[6.601247] [drm] Radeon Display Connectors
[6.602427] [drm] radeon: power management initialized
[6.722544] fbcon: radeondrmfb (fb0) is primary device
[6.945065] radeon :02:00.0: fb0: radeondrmfb frame buffer device
[6.945100] radeon :02:00.0: registered panic notifier
[6.945159] [drm] Initialized radeon 2.27.0 20080528 for :02:00.0 on
minor 0
At this point, I got tired of this experimenting and went and took the
big hammer :-):
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 49b06590001e..00214312db23 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -307,6 +307,11 @@ int radeon_wb_init(struct radeon_device *rdev)
rdev->wb.use_event = true;
}
+ if (rdev->wb.enabled) {
+ pr_err("%s: disable the goddam WB: radeon_no_wb: %d\n",
__func__, radeon_no_wb);
+ rdev->wb.enabled = false;
+ }
+
dev_info(rdev->dev, "WB %sabled\n", rdev->wb.enabled ? "en" : "dis");
return 0;
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1+ root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.no_wb no_wb
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1+
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.no_wb no_wb
[6.562905] [drm] radeon kernel modesetting enabled.
[6.565106] radeon :02:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[6.565172] radeon :02:00.0: GTT: 512M 0x2000 -
0x3FFF
[6.567696] [drm] radeon: 512M of VRAM memory ready
[6.567742] [drm] radeon: 512M of GTT memory ready.
[6.568068] radeon :02:00.0: irq 42 for MSI/MSI-X
[6.568130] radeon :02:00.0: radeon: using MSI.
[6.568269] [drm] radeon: irq initialized.
[6.684920] radeon_wb_init: disable the goddam WB: radeon_no_wb: 0
[6.684967] radeon :02:00.0: WB disabled
^^^
[6.685011] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x880221ea3c00
[6.685077] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x880221ea3c0c
[6.722367] [drm] Radeon Display Connectors
[6.723548] [drm] radeon: power management initialized
[6.843185] fbcon: radeondrmfb (fb0) is primary device
[7.066368] radeon :02:00.0: fb0: radeondrmfb frame buffer device
[7.066402] radeon :02:00.0: registered panic notifier
[7.066462] [drm] Initialized radeon 2.27.0 20080528 for :02:00.0 on
minor 0
Ok, I hope I turned off the proper WB thing (I'm assuming you meant the
radeon_no_wb paramet
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Borislav Petkov wrote: > [ 28.191072] radeon: `0' invalid for parameter `wb' > > although the whole driver blubber didn't appear on the console fterwards > aso something got turned off allright. > > Then, I went and tried "radeon.no_wb" where the driver blubber appeared > but AGP writeback was still enabled: no_wb=1 should work.
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote: > no_wb=1 should work. Yeah, maybe all those radeon and other GPU module parameters' syntax should be documented somewhere - Documentation/kernel-parameters.txt for example, or a GPU-specific file, whatever - so that we can save us all the time and confusion. Provided this hasn't happened yet, of course. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Borislav Petkov wrote: > On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote: >> no_wb=1 should work. > > Yeah, maybe all those radeon and other GPU module parameters' syntax > should be documented somewhere - Documentation/kernel-parameters.txt for > example, or a GPU-specific file, whatever - so that we can save us all > the time and confusion. Provided this hasn't happened yet, of course. modinfo radeon will give a list assuming you use modules, I think all of them need =.
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote: > modinfo radeon > > will give a list assuming you use modules, I think all of them need =. Yep, that is one way of getting that info, thanks. I always go and look at Documentation/kernel-parameters.txt and forget about modinfo. As you say 'radeon' needs to be module but since this is the case with the distros, the majority of Linux installations out there have it this way so we're fine. Btw, there's a typo in the param list, if anyone wants to write a patch for it :-): parm: lockup_timeout:GPU lockup timeout in ms (defaul 1 = 10 seconds, 0 = disable) (int) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 2012.12.23 at 12:31 +0100, Borislav Petkov wrote: > On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote: > > modinfo radeon > > > > will give a list assuming you use modules, I think all of them need =. > > Yep, that is one way of getting that info, thanks. I always go and look > at Documentation/kernel-parameters.txt and forget about modinfo. > > As you say 'radeon' needs to be module but since this is the case with > the distros, the majority of Linux installations out there have it this > way so we're fine. (If you don't use modules: git grep MODULE_PARM_DESC -- drivers/gpu/drm/radeon/ ) You may have hit the same issue as I, see: http://thread.gmane.org/gmane.comp.video.dri.devel/78328 Reverting commit 2d6cc729 fixes the problem for me, setting radeon.no_wb=1 doesn't help. -- Markus
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, 2012-12-23 at 11:01 +, Andy Furniss wrote: > Borislav Petkov wrote: > > > [ 28.191072] radeon: `0' invalid for parameter `wb' > > > > although the whole driver blubber didn't appear on the console fterwards > > aso something got turned off allright. > > > > Then, I went and tried "radeon.no_wb" where the driver blubber appeared > > but AGP writeback was still enabled: > > no_wb=1 should work. Perhaps some of the module_param_named(,,int,) should be bool Also, are all of the various permissions appropriate? $ git grep module_param_named drivers/gpu/drm/radeon/ drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(no_wb, radeon_no_wb, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(modeset, radeon_modeset, int, 0400); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(dynclks, radeon_dynclks, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(r4xx_atom, radeon_r4xx_atom, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(vramlimit, radeon_vram_limit, int, 0600); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(agpmode, radeon_agpmode, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(gartsize, radeon_gart_size, int, 0600); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(benchmark, radeon_benchmarking, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(test, radeon_testing, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(connector_table, radeon_connector_table, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(tv, radeon_tv, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(audio, radeon_audio, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(disp_priority, radeon_disp_priority, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(hw_i2c, radeon_hw_i2c, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(pcie_gen2, radeon_pcie_gen2, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(msi, radeon_msi, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(lockup_timeout, radeon_lockup_timeout, int, 0444);
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 12:51:33PM +0100, Markus Trippelsdorf wrote: > (If you don't use modules: git grep MODULE_PARM_DESC -- > drivers/gpu/drm/radeon/ ) Yeah. > You may have hit the same issue as I, see: > http://thread.gmane.org/gmane.comp.video.dri.devel/78328 Yes, it very much looks like it. That same page kills the machine here too. Maybe the GPU gets scared from the graphic nature of those images and gives up. :-D Although the box is not completely dead - I can login to a console and save dmesg before rebooting. And this bug becomes funnier and funnier - Alex, you might want to add that webpage to your testsuite :-). > Reverting commit 2d6cc729 fixes the problem for me, setting > radeon.no_wb=1 doesn't help. Right, let me try that and report back. Good job Markus, thanks! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote: > Right, let me try that and report back. Yep, looks like reverting the above commit fixes it - the boston.com website loads just fine. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[pull] radeon drm-next-3.8
2012/12/8 : > Alex Deucher (6): > drm/radeon/dce3.2: add registers for ELD handling > drm/radeon/dce4/5: add registers for ELD handling Sorry, I can't reply to the any of above patches. Alex: can we also get definition of (1 << 20) bit for AZ_HOT_PLUG_CONTROL? Just my curiosity :) -- Rafa?
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #2 from Bryan Quigley --- My kernel build does have that patch. Unfortunately, I am having trouble bisecting because something that appears unrelated makes my system fail to boot. That boot failure already been fixed in more recent builds thought :/. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/11372cc5/attachment.html>
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #3 from Alex Deucher --- Looks like this is probably a duplicate of this issue: http://lists.freedesktop.org/archives/dri-devel/2012-December/032547.html See if reverting commit 2d6cc729 fixes the problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/43faaa4e/attachment.html>
[PATCH] drm/radeon/6xx: disable use of the DMA ring for ttm bo moves
From: Alex Deucher
Seems to fall over in some cases with heavy memory thrashing on
6xx. Needs more investigation after the holidays, disable for
now.
Cc: Markus Trippelsdorf
Cc: Borislav Petkov
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 596bcbe..c66b92d 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -974,8 +974,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1058,8 +1058,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
--
1.7.7.5
[PATCH] drm/radeon/6xx: disable use of the DMA ring for ttm bo moves
On Sun, Dec 23, 2012 at 01:28:25PM -0500, alexdeucher at gmail.com wrote: > From: Alex Deucher > > Seems to fall over in some cases with heavy memory thrashing on > 6xx. Needs more investigation after the holidays, disable for > now. > > Cc: Markus Trippelsdorf > Cc: Borislav Petkov > Signed-off-by: Alex Deucher Yep, running with the revert doesn't show any other adverse effects so the real fix can take its time, relax and enjoy the holidays :-). I'll test this one tomorrow just in case, even though it looks trivial. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #6 from Thomas Rohloff --- Created attachment 72041 --> https://bugs.freedesktop.org/attachment.cgi?id=72041&action=edit New dmesg output Never mind, I found the patch here: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=33e5467871b3007c4e6deea95b2cac38a55ff9f5 I reverted it and no crash so far (but as they are random they might still occur). On the other side the dmesg messages are still there. Uploading the new output just in case it is needed. While writing this minecraft (which I used to trigger the crashes) crashed (right before and shortly after the crash the mouse wsq in slow-motion and I thought it will crash right away). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/13a1ca60/attachment-0001.html>
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #5 from Thomas Rohloff --- To add some more to this bug report: Some things in Minecraft aren't rendered at all: Water, Signs, Items (on the ground), all kind of mobs (animals, monsters, ...), the selection ring around blocks and maybe more. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/b4801019/attachment.html>
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #6 from Thomas Rohloff --- Whoever changed the report title: It is broken on the locked BIOS, not on the unlocked. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/f9b23b54/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #7 from Thomas Rohloff --- Crashes are still there after reverting "drm/radeon: use DMA engine for VM page table updates on cayman/TN" -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/224ee2fe/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #8 from Thomas Rohloff --- But this crash was different: The image froze but the monitor didn't go into standby nor came it back with garbage. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/6fcf7b21/attachment.html>
[Bug 58658] Minecraft menu broken on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58658 --- Comment #4 from Thomas Rohloff --- Bisected mesa. This is a mesa bug caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664 Can anybody move this to the right place or do I have to re-create the report (and if so: Where) ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/989fde55/attachment.html>
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 --- Comment #6 from Thomas Rohloff --- Bisected mesa. This is a mesa bug caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664 Can anybody move this to the right place or do I have to re-create the report (and if so: Where) ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/7e7df023/attachment.html>
[Bug 58660] Radeon HD 6950 completely broken with sapphire unlocked vbios
https://bugs.freedesktop.org/show_bug.cgi?id=58660 --- Comment #7 from Thomas Rohloff --- Bisected mesa. This is a mesa bug caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664 Can anybody move this to the right place or do I have to re-create the report (and if so: Where) ? I also think this is a duplication of https://bugs.freedesktop.org/show_bug.cgi?id=58667 - The crashes just occur way more often (right after starting compiz) with the locked BIOS. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/98b9adcf/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #9 from Thomas Rohloff --- Bisected mesa. This is a mesa bug caused by http://cgit.freedesktop.org/mesa/mesa/commit/?id=6532eb17baff6e61b427f29e076883f8941ae664 Can anybody move this to the right place or do I have to re-create the report (and if so: Where) ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/aa997b50/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #10 from Thomas Rohloff --- I was to fast with this. While the error messages in dmesg are gone it still randomly crashes, but this time the computer just froze completely. I think this bug report are in fact at least two bugs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/b0dc12cb/attachment.html>
[Bug 57842] r200: Culling is broken when rendering to an FBO
https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #5 from smoki --- Created attachment 72047 --> https://bugs.freedesktop.org/attachment.cgi?id=72047&action=edit Myr200FrontFace Seems like i managed to fix it, but with dirty hack... see function in attachment. tcl somehow is not aware of wind inverting, and i just inverted commands, but it works that way :). This fbo test case works, fbotexture and tri-cull from mesa demos - with both swtcl and tcl. What i tested, yeah Aquaria game is no more black with fbo usage and also Supertuxkart now show icons in minimap, etc. Anyhow, maybe someone know how to make that better to be acceptible for mesa and pushed in git - i don't know better :). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121223/48332ef1/attachment.html>
