[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 Alexandre Demers changed: What|Removed |Added Summary|Latest radeon dri driver on |Latest radeon dri driver on |HD6950 with GRUB set|HD6950 with GRUB set |gfxpayload=$linux_gfx_mode |"GRUB_GFXPAYLOAD_LINUX=keep |put the display in a|" put the display in a |flickering state|flickering state -- 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/20130329/9fba59cf/attachment.html>
[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #21 from Alexandre Demers --- So I'm trying to narrow down what is going on. Kernel 3.5 + patch 64759 works OK. I'm now testing kernel's commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 that was supposed to supersede patch 64759 in kernel 3.6. I'll see what I get. My feeling is we are not saving/restoring an address (VM, VRAM, TTM, whatever) correctly somewhere along the path. -- 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/20130329/551ad43c/attachment.html>
[Bug 55941] Hybrid graphics i915/radeon. Switch to radeon results to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=55941 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #3 from Alex Deucher 2013-03-29 20:59:13 --- You have a muxless powerxpress system so there are no displays physically connected to the radeon card. The only way to utilize the radeon card is for offscreen rendering (radeon renders application frame and the frame is copied to the intel card for display). You need the new gpu hotplug features in xserver 1.13.x or 1.14 to utilize the card in that manner. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #19 from D. Hugh Redelmeier --- More information about my Fedora 18 x86-64 configuration: - a single monitor: 2560 x 1600 pixels - video card: Radeon HD 3600 XT (according to Xorg.0.log) - Fedora's kernel: kernel-3.8.4-202.fc18.x86_64 - Fedora's mesa: mesa-debuginfo-9.1-3.fc18.x86_64 mesa-dri-drivers-9.1-3.fc18.x86_64 mesa-dri-filesystem-9.1-3.fc18.x86_64 mesa-libEGL-9.1-3.fc18.x86_64 mesa-libgbm-9.1-3.fc18.x86_64 mesa-libGL-9.1-3.fc18.x86_64 mesa-libglapi-9.1-3.fc18.x86_64 mesa-libGLU-9.0.0-1.fc18.x86_64 mesa-libGLU-debuginfo-9.0.0-1.fc18.x86_64 mesa-libxatracker-9.1-3.fc18.x86_64 I didn't have this problem when running Fedora 17. But I did have a bit of oddness: https://bugzilla.kernel.org/show_bug.cgi?id=49981#c5 Is anything else of interest? -- 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/20130329/4c2a3474/attachment.html>
[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #23 from Alexandre Demers --- (In reply to comment #22) > The current code should do the right thing with respect to disabling display > access to vram when we reconfigure the memory controller. The current code > disables memory reads but leaves the display controllers enabled while we > change the MC setup. Turning off the crtcs as the patch you mentioned does > has two problems: > 1. it breaks some systems which the current method fixes > 2. it defeats the purpose of GRUB_GFXPAYLOAD_LINUX=keep which is to avoid > turning off the displays for flickerless boot up. If you turn off the crtcs > you have to re-init the entire display pipeline. > The problem seems to be that disabling the crtc memory reads seems to take > longer than expected on some systems which leads to invalid reads while the > MC is being reprogrammed. One possible solution may be to leave the MC as > configured by the vbios and try and put the gart aperture either before or > after the location of varm in the GPU's address space. I understand what you are explaining. Meanwhile, I'm bisecting to find out where it was broken again since commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 does indeed what it is supposed to do (no problem when using GRUB_GFXPAYLOAD_LINUX=keep). So, somewhere between commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 and 3.9.0-rcx, something went wrong. I'll keep in touch. -- 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 55941] Hybrid graphics i915/radeon. Switch to radeon results to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=55941 --- Comment #2 from Dimitris Damigos 2013-03-29 18:54:12 --- I also tried 3.0.70 lts and instead of the screen turning off, it just freezes. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 55941] Hybrid graphics i915/radeon. Switch to radeon results to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=55941 --- Comment #1 from Dimitris Damigos 2013-03-29 18:53:19 --- Created an attachment (id=96621) --> (https://bugzilla.kernel.org/attachment.cgi?id=96621) dmesg -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 55941] New: Hybrid graphics i915/radeon. Switch to radeon results to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=55941 Summary: Hybrid graphics i915/radeon. Switch to radeon results to black screen Product: Drivers Version: 2.5 Kernel Version: 3.8.4 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: damigos at freemail.gr Regression: No Created an attachment (id=96611) --> (https://bugzilla.kernel.org/attachment.cgi?id=96611) lspci I have installed Arch Linux on a Dell Inspiron R15 with hybrid Intel/AMD graphics. vga_switcheroo is enabled and I can control radeon power with "echo ON/OFF > /sys/kernel/debug/vgaswitcheroo/switch". But when I try to switch to radeon in console with "echo DIS > /sys/kernel/debug/vgaswitcheroo/switch" the screen turns off. I can switch back to intel with "echo IGD > /sys/kernel/debug/vgaswitcheroo/switch" by blind typing it, and then the screen turns back on. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #18 from D. Hugh Redelmeier --- (Sorry for the previous uncompleted comment. I will continue.) I'm hitting it in Gnome_shell (https://bugzilla.redhat.com/show_bug.cgi?id=924076). I'm hitting it in Cinnamon (https://bugzilla.redhat.com/show_bug.cgi?id=926036) I'm hitting it in KWin (https://bugs.kde.org/show_bug.cgi?id=315089) In each case, I get a SIGBUS in __memset_sse2, called from r600 code. I'm not used to getting SIGBUSes since I migrated from the PDP-11 :-). This makes me think that it is a radeon driver bug. One KDE developer pointed in another direction. Since it is reported as an intel driver bug, I don't think that it is right, but it might be relevant: https://bugs.freedesktop.org/show_bug.cgi?id=58834 I think that I still have crash dumps for each of these. If something from them would be useful, ask soon before I recover the space. But I think that I can regenerate one all too quickly. -- 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/20130329/bab979b1/attachment.html>
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 D. Hugh Redelmeier changed: What|Removed |Added CC||hugh at mimosa.com --- Comment #17 from D. Hugh Redelmeier --- I think that I am hitting this bug on Fedora 18 x86-64 with all current updates (as of a couple of days ago). I'm hitting it in Gnome_shell ( -- 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/20130329/cfc42c82/attachment.html>
[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #22 from Alex Deucher --- The current code should do the right thing with respect to disabling display access to vram when we reconfigure the memory controller. The current code disables memory reads but leaves the display controllers enabled while we change the MC setup. Turning off the crtcs as the patch you mentioned does has two problems: 1. it breaks some systems which the current method fixes 2. it defeats the purpose of GRUB_GFXPAYLOAD_LINUX=keep which is to avoid turning off the displays for flickerless boot up. If you turn off the crtcs you have to re-init the entire display pipeline. The problem seems to be that disabling the crtc memory reads seems to take longer than expected on some systems which leads to invalid reads while the MC is being reprogrammed. One possible solution may be to leave the MC as configured by the vbios and try and put the gart aperture either before or after the location of varm in the GPU's address space. -- 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 61678] SNA causes problems with DRI_PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=61678 Alexander Mezin changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Assignee|intel-gfx-bugs at lists.freede |dri-devel at lists.freedesktop |sktop.org |.org QA Contact|intel-gfx-bugs at lists.freede | |sktop.org | Component|DRM/Intel |DRM/Radeon --- Comment #4 from Alexander Mezin --- It disappeared because I enabled LLVM shader compiler. With R600_USE_LLVM=0 the bug is still present (git drivers and mesa, kernel 3.8.5, xorg-server 1.13.1) How can I enable more verbose debug 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/20130329/d82a13cd/attachment-0001.html>
[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 Alexandre Demers changed: What|Removed |Added Summary|Latest radeon dri driver on |Latest radeon dri driver on |HD6950 with GRUB set|HD6950 with GRUB set |gfxpayload=$linux_gfx_mode |"GRUB_GFXPAYLOAD_LINUX=keep |put the display in a|" put the display in a |flickering state|flickering state -- 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 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #21 from Alexandre Demers --- So I'm trying to narrow down what is going on. Kernel 3.5 + patch 64759 works OK. I'm now testing kernel's commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 that was supposed to supersede patch 64759 in kernel 3.6. I'll see what I get. My feeling is we are not saving/restoring an address (VM, VRAM, TTM, whatever) correctly somewhere along the path. -- 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 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #12 from Thilo Cestonaro --- I tried both with the patched kernel, only ColorTiling2D and ColorTiling plus ColorTiling2D. The glitches still occur. Any other ideas? Greetings Thilo -- 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/20130329/869553ba/attachment.html>
[Bug 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 Hristo Venev changed: What|Removed |Added Attachment #77012|0 |1 is obsolete|| --- Comment #23 from Hristo Venev --- Created attachment 77211 --> https://bugs.freedesktop.org/attachment.cgi?id=77211&action=edit Outputs of avivotool avivotool while running fglrx nicely halts the GPU. Xorg wouldn't die so I couldn't switch to radeon. cold-fglrx-warm-radeon was from the next boot. -- 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/20130329/31ef2c60/attachment.html>
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #11 from Thilo Cestonaro --- Do you think, the Kernel patch fixed something which works together with the tiling option. If not, we tried this already last year (Nov.) http://lists.x.org/archives/xorg/2012-November/055131.html But I will give it a try. Greetings Thilo -- 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/20130329/62427374/attachment.html>
[Bug 55941] Hybrid graphics i915/radeon. Switch to radeon results to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=55941 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #3 from Alex Deucher 2013-03-29 20:59:13 --- You have a muxless powerxpress system so there are no displays physically connected to the radeon card. The only way to utilize the radeon card is for offscreen rendering (radeon renders application frame and the frame is copied to the intel card for display). You need the new gpu hotplug features in xserver 1.13.x or 1.14 to utilize the card in that manner. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #22 from Alex Deucher --- Ugh. Sorry. I told you the wrong option for avivotool so it dumped the wrong registers. It should be : avivotool regs all -- 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/20130329/90f0d823/attachment.html>
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #10 from Alex Deucher --- Does disabling tiling help? Option "ColorTiling2D" "false" in the device section of your xorg.conf? -- 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/20130329/c84666c8/attachment-0001.html>
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #19 from D. Hugh Redelmeier --- More information about my Fedora 18 x86-64 configuration: - a single monitor: 2560 x 1600 pixels - video card: Radeon HD 3600 XT (according to Xorg.0.log) - Fedora's kernel: kernel-3.8.4-202.fc18.x86_64 - Fedora's mesa: mesa-debuginfo-9.1-3.fc18.x86_64 mesa-dri-drivers-9.1-3.fc18.x86_64 mesa-dri-filesystem-9.1-3.fc18.x86_64 mesa-libEGL-9.1-3.fc18.x86_64 mesa-libgbm-9.1-3.fc18.x86_64 mesa-libGL-9.1-3.fc18.x86_64 mesa-libglapi-9.1-3.fc18.x86_64 mesa-libGLU-9.0.0-1.fc18.x86_64 mesa-libGLU-debuginfo-9.0.0-1.fc18.x86_64 mesa-libxatracker-9.1-3.fc18.x86_64 I didn't have this problem when running Fedora 17. But I did have a bit of oddness: https://bugzilla.kernel.org/show_bug.cgi?id=49981#c5 Is anything else of interest? -- 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
system death under oom - 3.7.9
On Fri, Mar 29, 2013 at 11:22 AM, Michal Hocko wrote: > On Wed 27-03-13 14:25:36, Ilia Mirkin wrote: >> Hello, >> >> My system died last night apparently due to OOM conditions. Note that >> I don't have any swap set up, but my understanding is that this is not >> required. The full log is at: http://pastebin.com/YCYUXWvV. It was in >> my messages, so I guess the system took a bit to die completely. > > This doesn't seem like OOM: > [615185.810509] DMA32 free:130456kB min:36364kB low:45452kB high:54544kB > active_anon:764604kB inactive_anon:13180kB active_file:1282040kB > inactive_file:910648kB unevictable:0kB isolated(anon):0kB isolated(file):0kB > present:3325056kB mlocked:0kB dirty:4472kB writeback:0kB mapped:42836kB > shmem:14388kB slab_reclaimable:155160kB slab_unreclaimable:13620kB > kernel_stack:576kB pagetables:8712kB unstable:0kB bounce:0kB free_cma:0kB > writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no > [615185.810511] lowmem_reserve[]: 0 0 2772 2772 > [615185.810517] Normal free:44288kB min:31044kB low:38804kB high:46564kB > active_anon:2099560kB inactive_anon:14416kB active_file:271972kB > inactive_file:69684kB unevictable:4kB isolated(anon):0kB isolated(file):0kB > present:2838528kB mlocked:4kB dirty:12kB writeback:0kB mapped:107868kB > shmem:17440kB slab_reclaimable:87304kB slab_unreclaimable:45452kB > kernel_stack:3648kB pagetables:42840kB unstable:0kB bounce:0kB free_cma:0kB > writeback_tmp:0kB pages_scanned:196 all_unreclaimable? no > > You are above above high watermark in the DMA32 zone and slightly bellow > high watermak in the Normal zone. > Your driver requested > [615185.810279] xlock: page allocation failure: order:4, mode:0xc0d0 > > which is GFP_KERNEL |__GFP_COMP|__GFP_ZERO which doesn't look so unusual but > > [615185.810521] DMA: 0*4kB 0*8kB 1*16kB 0*32kB 2*64kB 1*128kB 1*256kB 0*512kB > 1*1024kB 1*2048kB 3*4096kB = 15888kB > [615185.810527] DMA32: 5673*4kB 7213*8kB 2142*16kB 461*32kB 30*64kB 0*128kB > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 131340kB > [615185.810532] Normal: 3382*4kB 3121*8kB 355*16kB 11*32kB 0*64kB 0*128kB > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44528kB > > but you ran out of high order pages on DMA32 zone (and zone Normal looks > even worse). There are only 30 order-4 pages and I suppose that the > allocation failed on the watermark check for that order. > >> nouveau is somewhat implicated, as it is the first thing that hits an >> allocation failure in nouveau_vm_create, and has a subsequent warn in >> nouveau_mm_fini, but then there's a GPF in >> __alloc_skb/__kmalloc_track_caller (and I'm using SLUB). Here is a >> partial disassembly for __kmalloc_track_caller: > > I would start by checking whether the driver handles the allocation > failure properly and it doesn't clobber slab data from other allocations > (just a wild guess as I am not familiar with nouveau code at all). I'm not particularly familiar with it, adding dri-devel as nouveau appears to be a moderated list. Glancing at the code, if nouveau_vm_create fails, the drm_open code calls nouveau_cli_destroy, which in turn calls nouveau_mm_fini (down the line) which triggered the WARN on my system. This in turn means that some stuff doesn't get freed, but it shouldn't clobber slab data. But there's probably more going on... > >> >>0x811325b1 <+138>: e8 a0 60 56 00 callq >> 0x81698656 <__slab_alloc.constprop.68> >>0x811325b6 <+143>: 49 89 c4mov%rax,%r12 >>0x811325b9 <+146>: eb 27 jmp0x811325e2 >> <__kmalloc_track_caller+187> >>0x811325bb <+148>: 49 63 45 20 movslq 0x20(%r13),%rax >>0x811325bf <+152>: 48 8d 4a 01 lea0x1(%rdx),%rcx >>0x811325c3 <+156>: 49 8b 7d 00 mov0x0(%r13),%rdi >>0x811325c7 <+160>: 49 8b 1c 04 mov(%r12,%rax,1),%rbx >>0x811325cb <+164>: 4c 89 e0mov%r12,%rax >>0x811325ce <+167>: 48 8d 37lea(%rdi),%rsi >>0x811325d1 <+170>: e8 3a 38 1b 00 callq >> 0x812e5e10 >> >> The GPF happens at +160, which is in the argument setup for the >> cmpxchg in slab_alloc_node. I think it's the call to >> get_freepointer(). There was a similar bug report a while back, >> https://lkml.org/lkml/2011/5/23/199, and the recommendation was to run >> with slub debugging. Is that still the case, or is there a simpler >> explanation? I can't reproduce this at will, not sure how many times >> this has happened but definitely not many. >> >> -ilia >> -- >> 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/ > > -- > Michal Hocko > SUSE Labs
[Nouveau] [PATCH v2] drm/nouveau: wait for vblank on page flipping
On Fri, Mar 29, 2013 at 7:33 AM, Peter Hurley
wrote:
> On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> Oops, fixed to apply this time..
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
>> b/drivers/gpu/drm/nouveau/nouveau_display.c
>> index 4610c3a..020542e 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
>> @@ -593,7 +597,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct
>> drm_framebuffer *fb,
>>
>> /* Emit a page flip */
>> if (nv_device(drm->device)->card_type >= NV_50) {
>> - ret = nv50_display_flip_next(crtc, fb, chan, 0);
>> + ret = nv50_display_flip_next(crtc, fb, chan, 1);
>
> Why would this work?
Because, when I added the code to support all this I kept it in mind
and added a switch to use it.
Now. The reason I never switched this on is that (as I *already*
mentioned in #nouveau to Maarten about another patch to enable vblank
unconditionally in the DDX...) we already have huge problems with
memory bandwidth due to our cards usually starting up at low clock
speeds. When I added page flipping support it made a huge difference
to some games etc that were barely playable before.
So, it'd be really nice to be able to do this, yes. But, before I'll
accept the patches a few things need to happen. I'd have done it
before, but, I've always had higher priority things in the way (like,
fixing the reclocking issue...)..
1. Fix the X server so that the page flipping path (dri2.c, line 1125)
will be called even if theres no swap_interval set, this will allow
page flipping to be used even in the absence of a sync-to-vblank
request too.
2. Remove the GLXVBlank option from the nouveau ddx completely,
default it to on. The application/user can now control it via other
means anyway (drawable swap_interval).
3. Fix the DRM page flip ioctl to take a flag to request a non-vsync'd
flip, and hook that bit up to the nv50_display_flip_next() call
I think that's everything... This will let us support both the speed
improvements from flipping, and sync-to-vblank as the user chooses.
Ben.
>
>> if (ret) {
>> mutex_unlock(&chan->cli->mutex);
>> goto fail_unreserve;
>
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
[Bug 55941] Hybrid graphics i915/radeon. Switch to radeon results to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=55941 --- Comment #2 from Dimitris Damigos 2013-03-29 18:54:12 --- I also tried 3.0.70 lts and instead of the screen turning off, it just freezes. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55941] Hybrid graphics i915/radeon. Switch to radeon results to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=55941 --- Comment #1 from Dimitris Damigos 2013-03-29 18:53:19 --- Created an attachment (id=96621) --> (https://bugzilla.kernel.org/attachment.cgi?id=96621) dmesg -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55941] New: Hybrid graphics i915/radeon. Switch to radeon results to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=55941 Summary: Hybrid graphics i915/radeon. Switch to radeon results to black screen Product: Drivers Version: 2.5 Kernel Version: 3.8.4 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: dami...@freemail.gr Regression: No Created an attachment (id=96611) --> (https://bugzilla.kernel.org/attachment.cgi?id=96611) lspci I have installed Arch Linux on a Dell Inspiron R15 with hybrid Intel/AMD graphics. vga_switcheroo is enabled and I can control radeon power with "echo ON/OFF > /sys/kernel/debug/vgaswitcheroo/switch". But when I try to switch to radeon in console with "echo DIS > /sys/kernel/debug/vgaswitcheroo/switch" the screen turns off. I can switch back to intel with "echo IGD > /sys/kernel/debug/vgaswitcheroo/switch" by blind typing it, and then the screen turns back on. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #18 from D. Hugh Redelmeier --- (Sorry for the previous uncompleted comment. I will continue.) I'm hitting it in Gnome_shell (https://bugzilla.redhat.com/show_bug.cgi?id=924076). I'm hitting it in Cinnamon (https://bugzilla.redhat.com/show_bug.cgi?id=926036) I'm hitting it in KWin (https://bugs.kde.org/show_bug.cgi?id=315089) In each case, I get a SIGBUS in __memset_sse2, called from r600 code. I'm not used to getting SIGBUSes since I migrated from the PDP-11 :-). This makes me think that it is a radeon driver bug. One KDE developer pointed in another direction. Since it is reported as an intel driver bug, I don't think that it is right, but it might be relevant: https://bugs.freedesktop.org/show_bug.cgi?id=58834 I think that I still have crash dumps for each of these. If something from them would be useful, ask soon before I recover the space. But I think that I can regenerate one all too quickly. -- 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 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 D. Hugh Redelmeier changed: What|Removed |Added CC||h...@mimosa.com --- Comment #17 from D. Hugh Redelmeier --- I think that I am hitting this bug on Fedora 18 x86-64 with all current updates (as of a couple of days ago). I'm hitting it in Gnome_shell ( -- 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 61678] SNA causes problems with DRI_PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=61678 Alexander Mezin changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Component|DRM/Intel |DRM/Radeon --- Comment #4 from Alexander Mezin --- It disappeared because I enabled LLVM shader compiler. With R600_USE_LLVM=0 the bug is still present (git drivers and mesa, kernel 3.8.5, xorg-server 1.13.1) How can I enable more verbose debug output? -- 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: system death under oom - 3.7.9
On Fri, Mar 29, 2013 at 11:22 AM, Michal Hocko wrote: > On Wed 27-03-13 14:25:36, Ilia Mirkin wrote: >> Hello, >> >> My system died last night apparently due to OOM conditions. Note that >> I don't have any swap set up, but my understanding is that this is not >> required. The full log is at: http://pastebin.com/YCYUXWvV. It was in >> my messages, so I guess the system took a bit to die completely. > > This doesn't seem like OOM: > [615185.810509] DMA32 free:130456kB min:36364kB low:45452kB high:54544kB > active_anon:764604kB inactive_anon:13180kB active_file:1282040kB > inactive_file:910648kB unevictable:0kB isolated(anon):0kB isolated(file):0kB > present:3325056kB mlocked:0kB dirty:4472kB writeback:0kB mapped:42836kB > shmem:14388kB slab_reclaimable:155160kB slab_unreclaimable:13620kB > kernel_stack:576kB pagetables:8712kB unstable:0kB bounce:0kB free_cma:0kB > writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no > [615185.810511] lowmem_reserve[]: 0 0 2772 2772 > [615185.810517] Normal free:44288kB min:31044kB low:38804kB high:46564kB > active_anon:2099560kB inactive_anon:14416kB active_file:271972kB > inactive_file:69684kB unevictable:4kB isolated(anon):0kB isolated(file):0kB > present:2838528kB mlocked:4kB dirty:12kB writeback:0kB mapped:107868kB > shmem:17440kB slab_reclaimable:87304kB slab_unreclaimable:45452kB > kernel_stack:3648kB pagetables:42840kB unstable:0kB bounce:0kB free_cma:0kB > writeback_tmp:0kB pages_scanned:196 all_unreclaimable? no > > You are above above high watermark in the DMA32 zone and slightly bellow > high watermak in the Normal zone. > Your driver requested > [615185.810279] xlock: page allocation failure: order:4, mode:0xc0d0 > > which is GFP_KERNEL |__GFP_COMP|__GFP_ZERO which doesn't look so unusual but > > [615185.810521] DMA: 0*4kB 0*8kB 1*16kB 0*32kB 2*64kB 1*128kB 1*256kB 0*512kB > 1*1024kB 1*2048kB 3*4096kB = 15888kB > [615185.810527] DMA32: 5673*4kB 7213*8kB 2142*16kB 461*32kB 30*64kB 0*128kB > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 131340kB > [615185.810532] Normal: 3382*4kB 3121*8kB 355*16kB 11*32kB 0*64kB 0*128kB > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44528kB > > but you ran out of high order pages on DMA32 zone (and zone Normal looks > even worse). There are only 30 order-4 pages and I suppose that the > allocation failed on the watermark check for that order. > >> nouveau is somewhat implicated, as it is the first thing that hits an >> allocation failure in nouveau_vm_create, and has a subsequent warn in >> nouveau_mm_fini, but then there's a GPF in >> __alloc_skb/__kmalloc_track_caller (and I'm using SLUB). Here is a >> partial disassembly for __kmalloc_track_caller: > > I would start by checking whether the driver handles the allocation > failure properly and it doesn't clobber slab data from other allocations > (just a wild guess as I am not familiar with nouveau code at all). I'm not particularly familiar with it, adding dri-devel as nouveau appears to be a moderated list. Glancing at the code, if nouveau_vm_create fails, the drm_open code calls nouveau_cli_destroy, which in turn calls nouveau_mm_fini (down the line) which triggered the WARN on my system. This in turn means that some stuff doesn't get freed, but it shouldn't clobber slab data. But there's probably more going on... > >> >>0x811325b1 <+138>: e8 a0 60 56 00 callq >> 0x81698656 <__slab_alloc.constprop.68> >>0x811325b6 <+143>: 49 89 c4mov%rax,%r12 >>0x811325b9 <+146>: eb 27 jmp0x811325e2 >> <__kmalloc_track_caller+187> >>0x811325bb <+148>: 49 63 45 20 movslq 0x20(%r13),%rax >>0x811325bf <+152>: 48 8d 4a 01 lea0x1(%rdx),%rcx >>0x811325c3 <+156>: 49 8b 7d 00 mov0x0(%r13),%rdi >>0x811325c7 <+160>: 49 8b 1c 04 mov(%r12,%rax,1),%rbx >>0x811325cb <+164>: 4c 89 e0mov%r12,%rax >>0x811325ce <+167>: 48 8d 37lea(%rdi),%rsi >>0x811325d1 <+170>: e8 3a 38 1b 00 callq >> 0x812e5e10 >> >> The GPF happens at +160, which is in the argument setup for the >> cmpxchg in slab_alloc_node. I think it's the call to >> get_freepointer(). There was a similar bug report a while back, >> https://lkml.org/lkml/2011/5/23/199, and the recommendation was to run >> with slub debugging. Is that still the case, or is there a simpler >> explanation? I can't reproduce this at will, not sure how many times >> this has happened but definitely not many. >> >> -ilia >> -- >> 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/ > > -- > Michal Hocko > SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #9 from Thilo Cestonaro --- Forgot to mention, which versions I used. The Ubuntu I installed was raring latest with selfcompiled kernel 3.8.4 (from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-raring.git). Greetings, Thilo -- 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/20130329/9a0842a2/attachment.html>
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #12 from Thilo Cestonaro --- I tried both with the patched kernel, only ColorTiling2D and ColorTiling plus ColorTiling2D. The glitches still occur. Any other ideas? Greetings Thilo -- 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 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 Hristo Venev changed: What|Removed |Added Attachment #77012|0 |1 is obsolete|| --- Comment #23 from Hristo Venev --- Created attachment 77211 --> https://bugs.freedesktop.org/attachment.cgi?id=77211&action=edit Outputs of avivotool avivotool while running fglrx nicely halts the GPU. Xorg wouldn't die so I couldn't switch to radeon. cold-fglrx-warm-radeon was from the next boot. -- 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 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #11 from Thilo Cestonaro --- Do you think, the Kernel patch fixed something which works together with the tiling option. If not, we tried this already last year (Nov.) http://lists.x.org/archives/xorg/2012-November/055131.html But I will give it a try. Greetings Thilo -- 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] compat/compat-drivers/linux-next: fb skip_vt_switch
> > I looked in today's linux-next, and there seems to be only one > > initialization of this field, to true, and one test of this field. So > > perhaps the case for setting the field to false just isn't needed. > > Oh sorry now I get what you mean! I thought about this -- and yes I > decided to not add a bool false setting for the structure field given > that the assumption is this would not be something dynamic, and data > structure would be kzalloc()'d so by default they are 0. What do you do about the test, though? julia
[Bug 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #22 from Alex Deucher --- Ugh. Sorry. I told you the wrong option for avivotool so it dumped the wrong registers. It should be : avivotool regs all -- 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 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #10 from Alex Deucher --- Does disabling tiling help? Option "ColorTiling2D" "false" in the device section of your xorg.conf? -- 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 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #5 from Alexander von Gluck --- If I disable ColorTiling, Gnome doesn't load completely only showing the desktop wallpaper Errors about unable to find displaybuffer (or something like that... not sure of exact error) While the display is corrupt.. I *can* tell that acceleration is working due to the speed of the GUI compared to llvmpipe. -- 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/20130329/11f96f12/attachment.html>
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #4 from Alexander von Gluck --- Created attachment 77183 --> https://bugs.freedesktop.org/attachment.cgi?id=77183&action=edit Example of corruption -- 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/20130329/29f044e5/attachment.html>
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #3 from Alexander von Gluck --- Created attachment 77182 --> https://bugs.freedesktop.org/attachment.cgi?id=77182&action=edit dmesg wcolortile stable software version -- 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/20130329/0ef2c3ef/attachment.html>
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #2 from Alexander von Gluck --- Created attachment 77181 --> https://bugs.freedesktop.org/attachment.cgi?id=77181&action=edit xorgconf wcolortile stable software version -- 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/20130329/d8e283d3/attachment.html>
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #1 from Alexander von Gluck --- Created attachment 77180 --> https://bugs.freedesktop.org/attachment.cgi?id=77180&action=edit xorglog wcolortile stable software version -- 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/20130329/5aacbbde/attachment.html>
[Bug 62889] New: ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 Priority: medium Bug ID: 62889 Assignee: dri-devel at lists.freedesktop.org Summary: ColorTiling results in glitches on Radeon HD 7970 + Glamor Severity: normal Classification: Unclassified OS: Linux (All) Reporter: kallisti5 at unixzen.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Versions tried Stable: LLVM 3.2 + Mesa 9.1.1 + kernel 3.8.4 Mainline LLVM 3.3-devel + mesa 9.2-devel + kernel 3.8.4 Gnome Desktop. Attempting to use Glamor on the Radeon HD 7970 results in odd screen artifacts. Cursor is not effected however. worked with agd5f in irc without any luck -- 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/20130329/7ee93fb0/attachment.html>
[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 Alexandre Demers changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #20 from Alexandre Demers --- I'm reopening this bug for two reasons: -It is still happening with kernel 3.9.0-rc4 because attachment 64759 from bug 42373 seems to never have been pushed -It is not a duplicate of bug 42373 since attachment 64759 fixes current bug but not 42373 It would be nice to have a revised version of attachment 64759 that applies correctly on latest kernel, then to have it tested and pushed to kernel's git. -- 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/20130329/8a7ee1e1/attachment-0001.html>
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #9 from Thilo Cestonaro --- Forgot to mention, which versions I used. The Ubuntu I installed was raring latest with selfcompiled kernel 3.8.4 (from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-raring.git). Greetings, Thilo -- 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] compat/compat-drivers/linux-next: fb skip_vt_switch
On Thu, Mar 28, 2013 at 11:21 PM, Julia Lawall wrote: >> > I looked in today's linux-next, and there seems to be only one >> > initialization of this field, to true, and one test of this field. So >> > perhaps the case for setting the field to false just isn't needed. >> >> Oh sorry now I get what you mean! I thought about this -- and yes I >> decided to not add a bool false setting for the structure field given >> that the assumption is this would not be something dynamic, and data >> structure would be kzalloc()'d so by default they are 0. > > What do you do about the test, though? Return the value. Luis
