[Bug 34618] Slow text scrolling on tty after suspend-cycle
https://bugs.freedesktop.org/show_bug.cgi?id=34618 pete...@hottemptation.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #29 from pete...@hottemptation.org 2011-04-11 00:17:02 PDT --- commit 84ac7cdbdd0f04df6b96153f7a79127fd6e45467 Author: Suresh Siddha Date: Tue Mar 29 15:38:12 2011 -0700 x86, mtrr, pat: Fix one cpu getting out of sync during resume On laptops with core i5/i7, there were reports that after resume graphics workloads were performing poorly on a specific AP, while the other cpu's were ok. This was observed on a 32bit kernel specifically. Debug showed that the PAT init was not happening on that AP during resume and hence it contributing to the poor workload performance on that cpu. On this system, resume flow looked like this: 1. BP starts the resume sequence and we reinit BP's MTRR's/PAT early on using mtrr_bp_restore() 2. Resume sequence brings all AP's online 3. Resume sequence now kicks off the MTRR reinit on all the AP's. 4. For some reason, between point 2 and 3, we moved from BP to one of the AP's. My guess is that printk() during resume sequence is contributing to this. We don't see similar behavior with the 64bit kernel but there is no guarantee that at this point the remaining resume sequence (after AP's bringup) has to happen on BP. 5. set_mtrr() was assuming that we are still on BP and skipped the MTRR/PAT init on that cpu (because of 1 above) 6. But we were on an AP and this led to not reprogramming PAT on this cpu leading to bad performance. Fix this by doing unconditional mtrr_if->set_all() in set_mtrr() during MTRR/PAT init. This might be unnecessary if we are still running on BP. But it is of no harm and will guarantee that after resume, all the cpu's will be in sync with respect to the MTRR/PAT registers. Signed-off-by: Suresh Siddha LKML-Reference: <1301438292-28370-1-git-send-email-e...@anholt.net> Signed-off-by: Eric Anholt Tested-by: Keith Packard Cc: sta...@kernel.org[v2.6.32+] Signed-off-by: H. Peter Anvin --- I will write an email to everyone, that this bug occurs also on Corei5/7 in 64bit Long-Mode. Thanks for your help. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: restore only the mode of this driver on lastclose
On Mon, 11 Apr 2011 15:23:17 +1000, Dave Airlie wrote: > From: Dave Airlie > > This has always used a big hammer, but that hammer is probably > too big, I'm also not sure its necessary but at least this > should be safe. So the difference appears to be that the patch only restores the fbcon of a device for the lastclose of that device. That makes sense. However, would it not be better to make this a generic drm_fb_helper_restore_mode() as it sounds like something every driver should consider? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.25
My need for releasing libdrm at this moment is to get the bug fix out for running current Intel Mesa drivers with older kernels. But 2.4.25 looks to be an exciting release in its own right! Dave Airlie has added his dumb fb interface so that plymouth and friends can use a generic kms/fb backend, moving the complexity out of plymouth and down into the kernel where it already existed. And from Ilija Hadzic we an improvement to handle vblanks on more than 2 monitors. -Chris Ben Skeggs (1): Implement drmGetCap() to query device/driver capabilities Chris Wilson (2): intel: Also handle mrb_exec fallback with ring == I915_EXEC_RENDER configure: version bump for 2.4.25 release Daniel Vetter (1): Cleanup gen2 tiling confusion Dave Airlie (4): drm: add dumb interface libkms: add dumb support libdrm: oops fix get cap return value. drm_mode: fix types on recently added ioctls Ilija Hadzic (1): libdrm: (revised) vblank wait on crtc > 1 Javier Jardón (1): build: Update autotools configuration Kristian Høgsberg (1): Build modetest for all chipsets, always build modeprint Matt Turner (1): don't try to build modetest without libkms git tag: 2.4.25 http://dri.freedesktop.org/libdrm/libdrm-2.4.25.tar.bz2 MD5: f53dc4c72109b17908e4113c3b8addfe libdrm-2.4.25.tar.bz2 SHA1: b950f29cd1c4bb9f1c98a926486a47256b0a4194 libdrm-2.4.25.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.25.tar.gz MD5: e9636c60e67ed0f90b327b599e833514 libdrm-2.4.25.tar.gz SHA1: 3b90c39946aaf14af0e97956306e7e908327a629 libdrm-2.4.25.tar.gz -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36131] New: r600: unknown param 45 (PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL)
https://bugs.freedesktop.org/show_bug.cgi?id=36131 Summary: r600: unknown param 45 (PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL) Product: Mesa Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: b.bel...@gmail.com Since some days I get an error each time I run the GL stack (3D apps or glxinfo for instance) I am on Fedora 15, kernel 2.6.39-rc2, Mesa git (happens also with the Mesa packaged for F15). The error is : EE r600_pipe.c:431 r600_get_param - r600: unknown param 45 For instance : $ glxinfo | grep "OpenGL version string" EE r600_pipe.c:431 r600_get_param - r600: unknown param 45 OpenGL version string: 2.1 Mesa 7.11-devel (git-a26121f) Brian Paterni (https://bugs.freedesktop.org/show_bug.cgi?id=35434) looks at the code, it seems that '45' is mapped to PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL. Perhaps this is related to this recent patch http://lists.freedesktop.org/archives/mesa-dev/2011-March/006218.html (gallium: remove PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36131] r600: unknown param 45 (PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL)
https://bugs.freedesktop.org/show_bug.cgi?id=36131 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Olšák 2011-04-11 05:49:12 PDT --- Fixed with 5c477ab2de9fb2ad3b0e4ae53f5930f1288cb90e. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #14 from eric 2011-04-11 06:00:55 PDT --- This happens also with r300g + linux-2.6.38.2 + KMS. I can not always reproduce this GPU lockup, but working (scrolling, opening a new tab) with big or fullscreen windows seems to trigger this lockup... but not right after a reboot... so it's difficult to reproduce. Hopefully someone finds a better way to reproduce this lockup. When the lockup starts the display disappears (turns to black) for 1 or 2 seconds, then the next will happen: 1) display will return and everything will work again, but the next lockup will happen soon; 2) display will return but only mouse and keyboard are working, the display will be frozen except the mouse pointer can move around; I have to exit all running applications (alt+f4) blindly because the changes will not be seen, go to console (ctrl+alt+f1) and from there reboot the system. Switching to console (ctrl+alt+f1) usually works and there the display is working again, but killing and restarting X will not work, the only way to get X back is to reboot. During the lockup the kernel.log will be full of: kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to schedule IB ! kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(1). These lines are going for ever until I kill X. Some lockups looking like mine were solved by turning off 'EnablePageFlip' in xorg.conf or setting 'agpmode' to -1, 1 or 4 in modprobe.conf or exporting 'LIBGL_ALWAYS_INDIRECT=1'... none of these solutions worked for me. Maybe turning off KMS works, but without KMS certain things won't work/are different, so I try to keep using KMS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #15 from eric 2011-04-11 06:03:13 PDT --- Created an attachment (id=45475) --> (https://bugs.freedesktop.org/attachment.cgi?id=45475) kernel.log kernel.log during GPU lockup -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
[ Adding the dri-devel list ] On Mon, 2011-04-11 at 15:31 +0200, Gabriel Paubert wrote: > On Thu, Apr 07, 2011 at 04:04:35PM +0200, Michel Dänzer wrote: > > On Mit, 2011-04-06 at 22:43 +0200, Gabriel Paubert wrote: > > > > > > The probem is that, at least on one of my machines, the new driver > > > does not work: the system hangs (apparently solid, but it's before > > > networking starts up and I've not yet hooked up a serial console), > > > after the "radeon: ib pool ready" message. > > > > Does radeon.agpmode=-1 radeon.no_wb=1 help? > > > > You might be able to get more information via netconsole if you prevent > > the radeon module from loading automatically (or load it with > > radeon.modeset=0 first) and then load it e.g. via ssh with modeset=1. > > Loading the module with modeset=1 results in insmod blocked in > kernel state (not consuming CPU cycles either). The last kernel > message is always the same (ib pool ready). This seems to be > independent of agpmode and no_wb. The kernel messages when > loading the driver are: > > kernel: [drm] radeon kernel modesetting enabled. > kernel: checking generic (c000 14) vs hw (c000 1000) > kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing > generic driver > kernel: [drm] initializing kernel modesetting (RV530 0x1002:0x71C7). > kernel: radeon :f1:00.0: Using 64-bit DMA iommu bypass > kernel: [drm] register mmio base: 0xE800 > kernel: [drm] register mmio size: 65536 > kernel: radeon :f1:00.0: Invalid ROM contents > kernel: ATOM BIOS: X1650PRO > kernel: [drm] Generation 2 PCI interface, using max accessible memory > kernel: radeon :f1:00.0: VRAM: 512M 0x - > 0x1FFF (512M used) > kernel: radeon :f1:00.0: GTT: 512M 0x2000 - 0x3FFF > kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > kernel: [drm] Driver supports precise vblank timestamp query. > kernel: irq: irq 9 on host /mpic mapped to virtual irq 24 > kernel: u3msi: allocated virq 0x18 (hw 0x9) addr 0xf8004090 > kernel: radeon :f1:00.0: radeon: using MSI. Have you ruled out any MSI related problems? I think the IRQ not working could explain the symptoms... > kernel: [drm] radeon: irq initialized. > kernel: [drm] Detected VRAM RAM=512M, BAR=256M > kernel: [drm] RAM width 128bits DDR > kernel: [TTM] Zone kernel: Available graphics memory: 1002914 kiB. > kernel: [TTM] Initializing pool allocator. > kernel: [drm] radeon: 512M of VRAM memory ready > kernel: [drm] radeon: 512M of GTT memory ready. > kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 > kernel: [drm] radeon: 1 quad pipes, 2 z pipes initialized. > kernel: [drm] PCIE GART of 512M enabled (table at 0x0004). > kernel: radeon :f1:00.0: WB enabled Make sure this line changes to 'WB disabled' with no_wb=1. There's a writeback endianness bug with modeset=1, see http://lists.freedesktop.org/archives/dri-devel/2011-April/009960.html . > kernel: [drm] Loading R500 Microcode > kernel: [drm] radeon: ring at 0x20001000 > kernel: [drm] ring test succeeded in 6 usecs > kernel: [drm] radeon: ib pool ready. > For now, with modeset=0, agpmode=-1 and no_wb=1, the driver > seems to work. The agpmode and no_wb options only have an effect with modeset=1, and you don't seem to be using AGP anyway. :) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: restore only the mode of this driver on lastclose
On Mon, 11 Apr 2011 15:23:17 +1000, Dave Airlie wrote: > From: Dave Airlie > > This has always used a big hammer, but that hammer is probably > too big, I'm also not sure its necessary but at least this > should be safe. Am I correct in reading the drm_fb_helper_restore path as restoring the mode of each fbdev device in turn? If so, why would that ever be useful (aside from doing it for each inserted card)? -- keith.pack...@intel.com pgptwd7hkgXDI.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: restore only the mode of this driver on lastclose
On Mon, 11 Apr 2011 09:06:38 -0700, Keith Packard wrote: > On Mon, 11 Apr 2011 15:23:17 +1000, Dave Airlie wrote: > > From: Dave Airlie > > > > This has always used a big hammer, but that hammer is probably > > too big, I'm also not sure its necessary but at least this > > should be safe. > > Am I correct in reading the drm_fb_helper_restore path as restoring > the mode of each fbdev device in turn? If so, why would that ever be > useful (aside from doing it for each inserted card)? During panics? Just not lastclose. :) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: restore only the mode of this driver on lastclose
On Mon, 11 Apr 2011 18:31:21 +0100, Chris Wilson wrote: > During panics? Just not lastclose. :) I'm still mystified -- why is it useful to do more than one modesetting operation on the video card? -- keith.pack...@intel.com pgp8O8IQun1Se.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
suspend/resume stopped working
Hello, Aborting (Ctrl-Brake) suspend to disk process (s2disk) brakes drm/radeon. Please see the logs below: [..] [ 130.722206] snapshot_ioctl: ioctl '80083307' is deprecated and will be removed soon, update your suspend-to-disk utilities [ 130.70] Syncing filesystems ... done. [ 131.022029] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 131.034312] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 131.047640] snapshot_ioctl: ioctl '4004330c' is deprecated and will be removed soon, update your suspend-to-disk utilities [ 131.047752] snapshot_ioctl: ioctl '40083306' is deprecated and will be removed soon, update your suspend-to-disk utilities [ 131.047759] snapshot_ioctl: ioctl '40083303' is deprecated and will be removed soon, update your suspend-to-disk utilities [ 131.047871] PM: Preallocating image memory... done (allocated 82641 pages) [ 131.179814] PM: Allocated 330564 kbytes in 0.13 seconds (2542.80 MB/s) [ 131.179817] Suspending console(s) (use no_console_suspend to debug) [ 131.182797] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 131.183264] HDA Intel :01:00.1: PCI INT B disabled [ 131.183802] HDA Intel :00:1b.0: PCI INT A disabled [ 131.504654] PM: freeze of devices complete after 323.233 msecs [ 131.506566] PM: late freeze of devices complete after 1.904 msecs [ 131.506773] ACPI: Preparing to enter system sleep state S4 [ 131.531112] PM: Saving platform NVS memory [ 131.534328] Disabling non-boot CPUs ... [ 131.580177] CPU 1 is now offline [ 131.622812] CPU 2 is now offline [ 131.754363] CPU 3 is now offline [ 131.754367] lockdep: fixing up alternatives. [ 131.755297] Extended CMOS year: 2000 [ 131.755468] PM: Creating hibernation image: [ 131.908665] PM: Need to copy 86670 pages [ 132.509928] PM: Hibernation image created (86670 pages copied) [ 131.756026] Extended CMOS year: 2000 [ 131.756578] microcode: CPU0 updated to revision 0xc, date = 2010-06-10 [ 131.756606] Enabling non-boot CPUs ... [ 131.763890] lockdep: fixing up alternatives. [ 131.763904] Booting Node 0 Processor 1 APIC 0x1 [ 131.763908] smpboot cpu 1: start_ip = 98000 [ 131.881690] Switched to NOHz mode on CPU #1 [ 131.923128] NMI watchdog enabled, takes one hw-pmu counter. [ 131.924625] microcode: CPU1 updated to revision 0xc, date = 2010-06-10 [ 131.924656] CPU1 is up [ 131.924949] lockdep: fixing up alternatives. [ 131.924959] Booting Node 0 Processor 2 APIC 0x4 [ 131.924962] smpboot cpu 2: start_ip = 98000 [ 132.041707] Switched to NOHz mode on CPU #2 [ 132.083285] NMI watchdog enabled, takes one hw-pmu counter. [ 132.084938] microcode: CPU2 updated to revision 0xc, date = 2010-06-10 [ 132.084950] CPU2 is up [ 132.085415] lockdep: fixing up alternatives. [ 132.085460] Booting Node 0 Processor 3 APIC 0x5 [ 132.085463] smpboot cpu 3: start_ip = 98000 [ 132.201793] Switched to NOHz mode on CPU #3 [ 132.244130] NMI watchdog enabled, takes one hw-pmu counter. [ 132.245820] microcode: CPU3 updated to revision 0xc, date = 2010-06-10 [ 132.245834] CPU3 is up [ 132.248617] ACPI: Waking up from system sleep state S4 [ 132.324868] PM: early thaw of devices complete after 0.540 msecs [ 132.325292] pci :00:1e.0: setting latency timer to 64 [ 132.325386] radeon :01:00.0: power state changed by ACPI to D0 [ 132.325470] ahci :00:1f.2: restoring config space at offset 0x1 (was 0x2b00403, writing 0x2b00407) [ 132.325510] radeon :01:00.0: power state changed by ACPI to D0 [ 132.325547] ahci :00:1f.2: setting latency timer to 64 [ 132.325630] radeon :01:00.0: setting latency timer to 64 [ 132.325681] sd 0:0:0:0: [sda] Starting disk [ 132.338376] HDA Intel :00:1b.0: BAR 0: set to [mem 0xb410-0xb4103fff 64bit] (PCI address [0xb410-0xb4103fff]) [ 132.338381] HDA Intel :01:00.1: BAR 0: set to [mem 0xb402-0xb4023fff 64bit] (PCI address [0xb402-0xb4023fff]) [ 132.338413] HDA Intel :00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a) [ 132.338457] HDA Intel :00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10) [ 132.338470] HDA Intel :00:1b.0: restoring config space at offset 0x1 (was 0x10, writing 0x12) [ 132.338501] HDA Intel :01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 132.338511] HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 [ 132.338514] HDA Intel :01:00.1: setting latency timer to 64 [ 132.338522] HDA Intel :00:1b.0: setting latency timer to 64 [ 132.338612] HDA Intel :00:1b.0: irq 43 for MSI/MSI-X [ 132.338615] HDA Intel :01:00.1: irq 44 for MSI/MSI-X [ 132.350073] radeon :01:00.0: WB enabled [ 132.366610] [drm] ring test succeeded in 0 usecs [ 132.366676] [drm] ib test succeeded in 0 usecs [ 132.645181] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 132.649348] ata1.00: configured for UDMA/133 [ 132.658490] ata2: SATA link up 1.5 Gbps (SStat
[Bug 30052] Fails to start X with intel+Ati video, whith modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=30052 Sebastien Villemot changed: What|Removed |Added CC||sebastien.ville...@ens.fr --- Comment #12 from Sebastien Villemot 2011-04-11 21:46:12 --- I am affected a quite similar problem. I have a desktop PC with 2 graphics card: one Intel (bundled within i3 core cpu), and one Radeon. Using kernel 2.6.38 (Debian version 2.6.38-3), I get: Apr 11 22:30:50 brouzouf kernel: [5.820704] radeon :01:00.0: Invalid ROM contents Apr 11 22:30:50 brouzouf kernel: [5.820790] radeon :01:00.0: Invalid ROM contents Apr 11 22:30:50 brouzouf kernel: [5.820817] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM Apr 11 22:30:50 brouzouf kernel: [5.820843] radeon :01:00.0: Fatal error during GPU init Apr 11 22:30:50 brouzouf kernel: [5.820866] [drm] radeon: finishing device. Apr 11 22:30:50 brouzouf kernel: [5.820868] [TTM] Memory type 2 has not been initialized. My configuration works fine using kernel 2.6.32 (Debian version 2.6.32-31). I do not use any special boot option (hence I am using KMS, which is activated by default under Debian). Let me know if I can help in any way to help debugging this, I really need this to work. Thanks -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: suspend/resume stopped working
On Tue, Apr 12, 2011 at 12:02:28AM +0300, Sergey Senozhatsky wrote: > Hello, > Aborting (Ctrl-Brake) suspend to disk process (s2disk) brakes drm/radeon. Can you try to revert 69a07f0b117a40fcc1a479358d8e1f41793617f2 just to see if that is the culprit. > Please see the logs below: > > [..] > [ 130.722206] snapshot_ioctl: ioctl '80083307' is deprecated and will be > removed soon, update your suspend-to-disk utilities > [ 130.70] Syncing filesystems ... done. > [ 131.022029] Freezing user space processes ... (elapsed 0.01 seconds) done. > [ 131.034312] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) > done. > [ 131.047640] snapshot_ioctl: ioctl '4004330c' is deprecated and will be > removed soon, update your suspend-to-disk utilities > [ 131.047752] snapshot_ioctl: ioctl '40083306' is deprecated and will be > removed soon, update your suspend-to-disk utilities > [ 131.047759] snapshot_ioctl: ioctl '40083303' is deprecated and will be > removed soon, update your suspend-to-disk utilities > [ 131.047871] PM: Preallocating image memory... done (allocated 82641 pages) > [ 131.179814] PM: Allocated 330564 kbytes in 0.13 seconds (2542.80 MB/s) > [ 131.179817] Suspending console(s) (use no_console_suspend to debug) > [ 131.182797] sd 0:0:0:0: [sda] Synchronizing SCSI cache > [ 131.183264] HDA Intel :01:00.1: PCI INT B disabled > [ 131.183802] HDA Intel :00:1b.0: PCI INT A disabled > [ 131.504654] PM: freeze of devices complete after 323.233 msecs > [ 131.506566] PM: late freeze of devices complete after 1.904 msecs > [ 131.506773] ACPI: Preparing to enter system sleep state S4 > [ 131.531112] PM: Saving platform NVS memory > [ 131.534328] Disabling non-boot CPUs ... > [ 131.580177] CPU 1 is now offline > [ 131.622812] CPU 2 is now offline > [ 131.754363] CPU 3 is now offline > [ 131.754367] lockdep: fixing up alternatives. > [ 131.755297] Extended CMOS year: 2000 > [ 131.755468] PM: Creating hibernation image: > [ 131.908665] PM: Need to copy 86670 pages > [ 132.509928] PM: Hibernation image created (86670 pages copied) > [ 131.756026] Extended CMOS year: 2000 > [ 131.756578] microcode: CPU0 updated to revision 0xc, date = 2010-06-10 > [ 131.756606] Enabling non-boot CPUs ... > [ 131.763890] lockdep: fixing up alternatives. > [ 131.763904] Booting Node 0 Processor 1 APIC 0x1 > [ 131.763908] smpboot cpu 1: start_ip = 98000 > [ 131.881690] Switched to NOHz mode on CPU #1 > [ 131.923128] NMI watchdog enabled, takes one hw-pmu counter. > [ 131.924625] microcode: CPU1 updated to revision 0xc, date = 2010-06-10 > [ 131.924656] CPU1 is up > [ 131.924949] lockdep: fixing up alternatives. > [ 131.924959] Booting Node 0 Processor 2 APIC 0x4 > [ 131.924962] smpboot cpu 2: start_ip = 98000 > [ 132.041707] Switched to NOHz mode on CPU #2 > [ 132.083285] NMI watchdog enabled, takes one hw-pmu counter. > [ 132.084938] microcode: CPU2 updated to revision 0xc, date = 2010-06-10 > [ 132.084950] CPU2 is up > [ 132.085415] lockdep: fixing up alternatives. > [ 132.085460] Booting Node 0 Processor 3 APIC 0x5 > [ 132.085463] smpboot cpu 3: start_ip = 98000 > [ 132.201793] Switched to NOHz mode on CPU #3 > [ 132.244130] NMI watchdog enabled, takes one hw-pmu counter. > [ 132.245820] microcode: CPU3 updated to revision 0xc, date = 2010-06-10 > [ 132.245834] CPU3 is up > [ 132.248617] ACPI: Waking up from system sleep state S4 > [ 132.324868] PM: early thaw of devices complete after 0.540 msecs > [ 132.325292] pci :00:1e.0: setting latency timer to 64 > [ 132.325386] radeon :01:00.0: power state changed by ACPI to D0 > [ 132.325470] ahci :00:1f.2: restoring config space at offset 0x1 (was > 0x2b00403, writing 0x2b00407) > [ 132.325510] radeon :01:00.0: power state changed by ACPI to D0 > [ 132.325547] ahci :00:1f.2: setting latency timer to 64 > [ 132.325630] radeon :01:00.0: setting latency timer to 64 > [ 132.325681] sd 0:0:0:0: [sda] Starting disk > [ 132.338376] HDA Intel :00:1b.0: BAR 0: set to [mem > 0xb410-0xb4103fff 64bit] (PCI address [0xb410-0xb4103fff]) > [ 132.338381] HDA Intel :01:00.1: BAR 0: set to [mem > 0xb402-0xb4023fff 64bit] (PCI address [0xb402-0xb4023fff]) > [ 132.338413] HDA Intel :00:1b.0: restoring config space at offset 0xf > (was 0x100, writing 0x10a) > [ 132.338457] HDA Intel :00:1b.0: restoring config space at offset 0x3 > (was 0x0, writing 0x10) > [ 132.338470] HDA Intel :00:1b.0: restoring config space at offset 0x1 > (was 0x10, writing 0x12) > [ 132.338501] HDA Intel :01:00.1: PCI INT B -> GSI 17 (level, low) -> > IRQ 17 > [ 132.338511] HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> > IRQ 22 > [ 132.338514] HDA Intel :01:00.1: setting latency timer to 64 > [ 132.338522] HDA Intel :00:1b.0: setting latency timer to 64 > [ 132.338612] HDA Intel :00:1b.0: irq 43 for MSI/MSI-X > [ 132.338615] HDA Intel :0
[Bug 35998] Artifacts under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #4 from Milan Plzik 2011-04-11 15:20:55 PDT --- Created an attachment (id=45494) --> (https://bugs.freedesktop.org/attachment.cgi?id=45494) glxinfo output Same happens to me, lspci output is: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Xpress 1250 hardware is Dell Latitude XT. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 Andrew Morton changed: What|Removed |Added CC||a...@linux-foundation.org Component|Video(Other)|Video(DRI - non Intel) AssignedTo|drivers_video-other@kernel- |drivers_video-dri@kernel-bu |bugs.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 Rafael J. Wysocki changed: What|Removed |Added CC||flor...@mickler.org, ||maciej.rute...@gmail.com, ||r...@sisk.pl Blocks||32012 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2011-04-11 23:14:27 --- Is this a regression? Did previous kernels work ok? If so, can you bisect? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 --- Comment #2 from Alex Deucher 2011-04-11 23:15:20 --- Does it work ok if you remove: vga=0x31a nomodesetting from your grub entry? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29842] Radeon runs very hot
https://bugzilla.kernel.org/show_bug.cgi?id=29842 Mike Meehan changed: What|Removed |Added CC||mjmee...@gmail.com --- Comment #8 from Mike Meehan 2011-04-12 01:22:03 --- My system is also impacted, noticed since upgrading to Ubuntu Natty. Kernel version 2.6.38-8.41-generic. Under no load my video card is reporting 82 degrees Celsius. The graphics card is a ATI Technologies Inc Barts PRO [ATI Radeon HD 6800 Series]. I'm using the radeon kernel module with the radeondrmfb frame buffer device. I think it's related to putting the console in framebuffer mode, the card is quiet in text mode. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29842] Radeon runs very hot
https://bugzilla.kernel.org/show_bug.cgi?id=29842 --- Comment #9 from Mike Meehan 2011-04-12 02:26:49 --- # echo low > /sys/class/drm/card0/device/power_profile "resolves" the issue. Default power management settings for KMS put the card in high performance mode on AC power. # echo dynpm > /sys/class/drm/card0/device/power_method Dynamic frequency scaling may work for you, though the screen flashes when power levels change. Still seems to run too hot. I'm sticking to low for most purposes. This page was very helpful: https://wiki.archlinux.org/index.php?title=ATI&oldid=135045 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33867] [bisected] Graphics corruption related to pageflip ioctl support in 2.6.38-rc*
https://bugs.freedesktop.org/show_bug.cgi?id=33867 --- Comment #14 from Dave Witbrodt 2011-04-11 19:59:28 PDT --- I did no further testing after the onset of the Japan crisis, but I have just started updating some relevant parts of my system. Updating from kernel 2.6.38-rc8 to 2.6.38.2 did not seem to have an effect, but updating Mesa to 7.11.0-devel (commit a26121f3) changed the observed behavior in prboom-plus. The black melts are gone, replaced by transient graphics corruption when starting a new game. This corruption fades within a span of about 1 second, and causes no further problems. In short, it looks like the problem was a combination of kernel changes and Mesa support for my Radeon HD 5750. Apparently some changes to Mesa over the past 7 weeks have resolved the problem I was originally reporting here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34156] r600g performance regression between 780c183b and 862ebb41
https://bugs.freedesktop.org/show_bug.cgi?id=34156 --- Comment #9 from Dave Witbrodt 2011-04-11 20:15:22 PDT --- I have been away from Linux and testing radeon support since the Japan crisis began. Updating to Mesa 7.11.0-devel, commit a26121f3, caused the same slowdown I had observed before: min/max framerate in 'torcs' dropped from 28/54 fps to 17/34 fps. I was planning on restoring local packages of my last fast-working Mesa, but decided to rebuild my entire X stack against my newly updated kernel (updated from 2.6.38-rc8 to 2.6.38.2). To my shock, I found that replacing xorg-server 1.9.99.903 with 1.10.0.902 and updating the radeon driver to the latest git version, 6.14.99-devel, commit cc7d1fa3 -- both built against the Mesa mentioned above -- improved Mesa performance in 'torcs' dramatically. It is no longer as consistently high as I was getting, but gives me 17/54 fps. I also notice that another test program, 'prboom-plus', has dramatically improved performance all around. As a result, I am abandoning my local git branch where I intended to pin down the exact cause of the performance changes -- I haven't touch it for 7 weeks anyway -- and start following the Mesa HEAD again. Sorry for the false alarm. It appears that Mesa changes alone were not to blame for whatever performance problems I was experiencing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34493] r600g performance regression introduced by 467023e8 (Marek Olšák: r600g: use the same upload buffer for vertices, indices, and constants)
https://bugs.freedesktop.org/show_bug.cgi?id=34493 --- Comment #7 from Dave Witbrodt 2011-04-11 20:15:46 PDT --- I have been away from Linux and testing radeon support since the Japan crisis began. Updating to Mesa 7.11.0-devel, commit a26121f3, caused the same slowdown I had observed before: min/max framerate in 'torcs' dropped from 28/54 fps to 17/34 fps. I was planning on restoring local packages of my last fast-working Mesa, but decided to rebuild my entire X stack against my newly updated kernel (updated from 2.6.38-rc8 to 2.6.38.2). To my shock, I found that replacing xorg-server 1.9.99.903 with 1.10.0.902 and updating the radeon driver to the latest git version, 6.14.99-devel, commit cc7d1fa3 -- both built against the Mesa mentioned above -- improved Mesa performance in 'torcs' dramatically. It is no longer as consistently high as I was getting, but gives me 17/54 fps. I also notice that another test program, 'prboom-plus', has dramatically improved performance all around. As a result, I am abandoning my local git branch where I intended to pin down the exact cause of the performance changes -- I haven't touch it for 7 weeks anyway -- and start following the Mesa HEAD again. Sorry for the false alarm. It appears that Mesa changes alone were not to blame for whatever performance problems I was experiencing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: restore only the mode of this driver on lastclose
From: Dave Airlie
This has always used a big hammer, but that hammer is probably
too big, I'm also not sure its necessary but at least this
should be safe.
Should fix: https://bugzilla.kernel.org/show_bug.cgi?id=23592
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_fb.c | 16
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 7273037..12876f2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2207,7 +2207,7 @@ void i915_driver_lastclose(struct drm_device * dev)
drm_i915_private_t *dev_priv = dev->dev_private;
if (!dev_priv || drm_core_check_feature(dev, DRIVER_MODESET)) {
- drm_fb_helper_restore();
+ intel_fb_restore_mode(dev);
vga_switcheroo_process_delayed_switch();
return;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f5b0d83..1d20712 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -338,4 +338,5 @@ extern int intel_overlay_attrs(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
extern void intel_fb_output_poll_changed(struct drm_device *dev);
+extern void intel_fb_restore_mode(struct drm_device *dev);
#endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 5127827..96a45c4 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -264,3 +264,19 @@ void intel_fb_output_poll_changed(struct drm_device *dev)
drm_i915_private_t *dev_priv = dev->dev_private;
drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
}
+
+void intel_fb_restore_mode(struct drm_device *dev)
+{
+ drm_i915_private_t *dev_priv = dev->dev_private;
+ int ret, i;
+
+ if (!dev_priv->fbdev)
+ return;
+
+ for (i = 0; i < dev_priv->fbdev->helper.crtc_count; i++) {
+ struct drm_mode_set *mode_set =
&dev_priv->fbdev->helper.crtc_info[i].mode_set;
+ ret = drm_crtc_helper_set_config(mode_set);
+ if (ret)
+ DRM_DEBUG("failed to restore crtc mode\n");
+ }
+}
--
1.7.1
[Bug 34618] Slow text scrolling on tty after suspend-cycle
https://bugs.freedesktop.org/show_bug.cgi?id=34618 peterle at hottemptation.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #29 from peterle at hottemptation.org 2011-04-11 00:17:02 PDT --- commit 84ac7cdbdd0f04df6b96153f7a79127fd6e45467 Author: Suresh Siddha Date: Tue Mar 29 15:38:12 2011 -0700 x86, mtrr, pat: Fix one cpu getting out of sync during resume On laptops with core i5/i7, there were reports that after resume graphics workloads were performing poorly on a specific AP, while the other cpu's were ok. This was observed on a 32bit kernel specifically. Debug showed that the PAT init was not happening on that AP during resume and hence it contributing to the poor workload performance on that cpu. On this system, resume flow looked like this: 1. BP starts the resume sequence and we reinit BP's MTRR's/PAT early on using mtrr_bp_restore() 2. Resume sequence brings all AP's online 3. Resume sequence now kicks off the MTRR reinit on all the AP's. 4. For some reason, between point 2 and 3, we moved from BP to one of the AP's. My guess is that printk() during resume sequence is contributing to this. We don't see similar behavior with the 64bit kernel but there is no guarantee that at this point the remaining resume sequence (after AP's bringup) has to happen on BP. 5. set_mtrr() was assuming that we are still on BP and skipped the MTRR/PAT init on that cpu (because of 1 above) 6. But we were on an AP and this led to not reprogramming PAT on this cpu leading to bad performance. Fix this by doing unconditional mtrr_if->set_all() in set_mtrr() during MTRR/PAT init. This might be unnecessary if we are still running on BP. But it is of no harm and will guarantee that after resume, all the cpu's will be in sync with respect to the MTRR/PAT registers. Signed-off-by: Suresh Siddha LKML-Reference: <1301438292-28370-1-git-send-email-eric at anholt.net> Signed-off-by: Eric Anholt Tested-by: Keith Packard Cc: stable at kernel.org[v2.6.32+] Signed-off-by: H. Peter Anvin --- I will write an email to everyone, that this bug occurs also on Corei5/7 in 64bit Long-Mode. Thanks for your help. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] i915: restore only the mode of this driver on lastclose
On Mon, 11 Apr 2011 15:23:17 +1000, Dave Airlie wrote: > From: Dave Airlie > > This has always used a big hammer, but that hammer is probably > too big, I'm also not sure its necessary but at least this > should be safe. So the difference appears to be that the patch only restores the fbcon of a device for the lastclose of that device. That makes sense. However, would it not be better to make this a generic drm_fb_helper_restore_mode() as it sounds like something every driver should consider? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[ANNOUNCE] libdrm 2.4.25
My need for releasing libdrm at this moment is to get the bug fix out for running current Intel Mesa drivers with older kernels. But 2.4.25 looks to be an exciting release in its own right! Dave Airlie has added his dumb fb interface so that plymouth and friends can use a generic kms/fb backend, moving the complexity out of plymouth and down into the kernel where it already existed. And from Ilija Hadzic we an improvement to handle vblanks on more than 2 monitors. -Chris Ben Skeggs (1): Implement drmGetCap() to query device/driver capabilities Chris Wilson (2): intel: Also handle mrb_exec fallback with ring == I915_EXEC_RENDER configure: version bump for 2.4.25 release Daniel Vetter (1): Cleanup gen2 tiling confusion Dave Airlie (4): drm: add dumb interface libkms: add dumb support libdrm: oops fix get cap return value. drm_mode: fix types on recently added ioctls Ilija Hadzic (1): libdrm: (revised) vblank wait on crtc > 1 Javier Jard??n (1): build: Update autotools configuration Kristian H??gsberg (1): Build modetest for all chipsets, always build modeprint Matt Turner (1): don't try to build modetest without libkms git tag: 2.4.25 http://dri.freedesktop.org/libdrm/libdrm-2.4.25.tar.bz2 MD5: f53dc4c72109b17908e4113c3b8addfe libdrm-2.4.25.tar.bz2 SHA1: b950f29cd1c4bb9f1c98a926486a47256b0a4194 libdrm-2.4.25.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.25.tar.gz MD5: e9636c60e67ed0f90b327b599e833514 libdrm-2.4.25.tar.gz SHA1: 3b90c39946aaf14af0e97956306e7e908327a629 libdrm-2.4.25.tar.gz -- Chris Wilson, Intel Open Source Technology Centre
[Bug 36131] New: r600: unknown param 45 (PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL)
https://bugs.freedesktop.org/show_bug.cgi?id=36131 Summary: r600: unknown param 45 (PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL) Product: Mesa Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: b.bellec at gmail.com Since some days I get an error each time I run the GL stack (3D apps or glxinfo for instance) I am on Fedora 15, kernel 2.6.39-rc2, Mesa git (happens also with the Mesa packaged for F15). The error is : EE r600_pipe.c:431 r600_get_param - r600: unknown param 45 For instance : $ glxinfo | grep "OpenGL version string" EE r600_pipe.c:431 r600_get_param - r600: unknown param 45 OpenGL version string: 2.1 Mesa 7.11-devel (git-a26121f) Brian Paterni (https://bugs.freedesktop.org/show_bug.cgi?id=35434) looks at the code, it seems that '45' is mapped to PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL. Perhaps this is related to this recent patch http://lists.freedesktop.org/archives/mesa-dev/2011-March/006218.html (gallium: remove PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36131] r600: unknown param 45 (PIPE_CAP_VERTEX_COLOR_CLAMP_CONTROL)
https://bugs.freedesktop.org/show_bug.cgi?id=36131 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Ol??k 2011-04-11 05:49:12 PDT --- Fixed with 5c477ab2de9fb2ad3b0e4ae53f5930f1288cb90e. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #14 from eric 2011-04-11 06:00:55 PDT --- This happens also with r300g + linux-2.6.38.2 + KMS. I can not always reproduce this GPU lockup, but working (scrolling, opening a new tab) with big or fullscreen windows seems to trigger this lockup... but not right after a reboot... so it's difficult to reproduce. Hopefully someone finds a better way to reproduce this lockup. When the lockup starts the display disappears (turns to black) for 1 or 2 seconds, then the next will happen: 1) display will return and everything will work again, but the next lockup will happen soon; 2) display will return but only mouse and keyboard are working, the display will be frozen except the mouse pointer can move around; I have to exit all running applications (alt+f4) blindly because the changes will not be seen, go to console (ctrl+alt+f1) and from there reboot the system. Switching to console (ctrl+alt+f1) usually works and there the display is working again, but killing and restarting X will not work, the only way to get X back is to reboot. During the lockup the kernel.log will be full of: kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to schedule IB ! kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(1). These lines are going for ever until I kill X. Some lockups looking like mine were solved by turning off 'EnablePageFlip' in xorg.conf or setting 'agpmode' to -1, 1 or 4 in modprobe.conf or exporting 'LIBGL_ALWAYS_INDIRECT=1'... none of these solutions worked for me. Maybe turning off KMS works, but without KMS certain things won't work/are different, so I try to keep using KMS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #15 from eric 2011-04-11 06:03:13 PDT --- Created an attachment (id=45475) --> (https://bugs.freedesktop.org/attachment.cgi?id=45475) kernel.log kernel.log during GPU lockup -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
[ Adding the dri-devel list ] On Mon, 2011-04-11 at 15:31 +0200, Gabriel Paubert wrote: > On Thu, Apr 07, 2011 at 04:04:35PM +0200, Michel D?nzer wrote: > > On Mit, 2011-04-06 at 22:43 +0200, Gabriel Paubert wrote: > > > > > > The probem is that, at least on one of my machines, the new driver > > > does not work: the system hangs (apparently solid, but it's before > > > networking starts up and I've not yet hooked up a serial console), > > > after the "radeon: ib pool ready" message. > > > > Does radeon.agpmode=-1 radeon.no_wb=1 help? > > > > You might be able to get more information via netconsole if you prevent > > the radeon module from loading automatically (or load it with > > radeon.modeset=0 first) and then load it e.g. via ssh with modeset=1. > > Loading the module with modeset=1 results in insmod blocked in > kernel state (not consuming CPU cycles either). The last kernel > message is always the same (ib pool ready). This seems to be > independent of agpmode and no_wb. The kernel messages when > loading the driver are: > > kernel: [drm] radeon kernel modesetting enabled. > kernel: checking generic (c000 14) vs hw (c000 1000) > kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing > generic driver > kernel: [drm] initializing kernel modesetting (RV530 0x1002:0x71C7). > kernel: radeon :f1:00.0: Using 64-bit DMA iommu bypass > kernel: [drm] register mmio base: 0xE800 > kernel: [drm] register mmio size: 65536 > kernel: radeon :f1:00.0: Invalid ROM contents > kernel: ATOM BIOS: X1650PRO > kernel: [drm] Generation 2 PCI interface, using max accessible memory > kernel: radeon :f1:00.0: VRAM: 512M 0x - > 0x1FFF (512M used) > kernel: radeon :f1:00.0: GTT: 512M 0x2000 - 0x3FFF > kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > kernel: [drm] Driver supports precise vblank timestamp query. > kernel: irq: irq 9 on host /mpic mapped to virtual irq 24 > kernel: u3msi: allocated virq 0x18 (hw 0x9) addr 0xf8004090 > kernel: radeon :f1:00.0: radeon: using MSI. Have you ruled out any MSI related problems? I think the IRQ not working could explain the symptoms... > kernel: [drm] radeon: irq initialized. > kernel: [drm] Detected VRAM RAM=512M, BAR=256M > kernel: [drm] RAM width 128bits DDR > kernel: [TTM] Zone kernel: Available graphics memory: 1002914 kiB. > kernel: [TTM] Initializing pool allocator. > kernel: [drm] radeon: 512M of VRAM memory ready > kernel: [drm] radeon: 512M of GTT memory ready. > kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 > kernel: [drm] radeon: 1 quad pipes, 2 z pipes initialized. > kernel: [drm] PCIE GART of 512M enabled (table at 0x0004). > kernel: radeon :f1:00.0: WB enabled Make sure this line changes to 'WB disabled' with no_wb=1. There's a writeback endianness bug with modeset=1, see http://lists.freedesktop.org/archives/dri-devel/2011-April/009960.html . > kernel: [drm] Loading R500 Microcode > kernel: [drm] radeon: ring at 0x20001000 > kernel: [drm] ring test succeeded in 6 usecs > kernel: [drm] radeon: ib pool ready. > For now, with modeset=0, agpmode=-1 and no_wb=1, the driver > seems to work. The agpmode and no_wb options only have an effect with modeset=1, and you don't seem to be using AGP anyway. :) -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
[PATCH] i915: restore only the mode of this driver on lastclose
On Mon, 11 Apr 2011 15:23:17 +1000, Dave Airlie wrote: > From: Dave Airlie > > This has always used a big hammer, but that hammer is probably > too big, I'm also not sure its necessary but at least this > should be safe. Am I correct in reading the drm_fb_helper_restore path as restoring the mode of each fbdev device in turn? If so, why would that ever be useful (aside from doing it for each inserted card)? -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110411/a7cfb324/attachment.pgp>
[PATCH] i915: restore only the mode of this driver on lastclose
On Mon, 11 Apr 2011 09:06:38 -0700, Keith Packard wrote: > On Mon, 11 Apr 2011 15:23:17 +1000, Dave Airlie wrote: > > From: Dave Airlie > > > > This has always used a big hammer, but that hammer is probably > > too big, I'm also not sure its necessary but at least this > > should be safe. > > Am I correct in reading the drm_fb_helper_restore path as restoring > the mode of each fbdev device in turn? If so, why would that ever be > useful (aside from doing it for each inserted card)? During panics? Just not lastclose. :) -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] i915: restore only the mode of this driver on lastclose
On Mon, 11 Apr 2011 18:31:21 +0100, Chris Wilson wrote: > During panics? Just not lastclose. :) I'm still mystified -- why is it useful to do more than one modesetting operation on the video card? -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110411/14189bbf/attachment.pgp>
[Bug 30052] Fails to start X with intel+Ati video, whith modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=30052 Sebastien Villemot changed: What|Removed |Added CC||sebastien.villemot at ens.fr --- Comment #12 from Sebastien Villemot 2011-04-11 21:46:12 --- I am affected a quite similar problem. I have a desktop PC with 2 graphics card: one Intel (bundled within i3 core cpu), and one Radeon. Using kernel 2.6.38 (Debian version 2.6.38-3), I get: Apr 11 22:30:50 brouzouf kernel: [5.820704] radeon :01:00.0: Invalid ROM contents Apr 11 22:30:50 brouzouf kernel: [5.820790] radeon :01:00.0: Invalid ROM contents Apr 11 22:30:50 brouzouf kernel: [5.820817] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM Apr 11 22:30:50 brouzouf kernel: [5.820843] radeon :01:00.0: Fatal error during GPU init Apr 11 22:30:50 brouzouf kernel: [5.820866] [drm] radeon: finishing device. Apr 11 22:30:50 brouzouf kernel: [5.820868] [TTM] Memory type 2 has not been initialized. My configuration works fine using kernel 2.6.32 (Debian version 2.6.32-31). I do not use any special boot option (hence I am using KMS, which is activated by default under Debian). Let me know if I can help in any way to help debugging this, I really need this to work. Thanks -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
suspend/resume stopped working
On Tue, Apr 12, 2011 at 12:02:28AM +0300, Sergey Senozhatsky wrote: > Hello, > Aborting (Ctrl-Brake) suspend to disk process (s2disk) brakes drm/radeon. Can you try to revert 69a07f0b117a40fcc1a479358d8e1f41793617f2 just to see if that is the culprit. > Please see the logs below: > > [..] > [ 130.722206] snapshot_ioctl: ioctl '80083307' is deprecated and will be > removed soon, update your suspend-to-disk utilities > [ 130.70] Syncing filesystems ... done. > [ 131.022029] Freezing user space processes ... (elapsed 0.01 seconds) done. > [ 131.034312] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) > done. > [ 131.047640] snapshot_ioctl: ioctl '4004330c' is deprecated and will be > removed soon, update your suspend-to-disk utilities > [ 131.047752] snapshot_ioctl: ioctl '40083306' is deprecated and will be > removed soon, update your suspend-to-disk utilities > [ 131.047759] snapshot_ioctl: ioctl '40083303' is deprecated and will be > removed soon, update your suspend-to-disk utilities > [ 131.047871] PM: Preallocating image memory... done (allocated 82641 pages) > [ 131.179814] PM: Allocated 330564 kbytes in 0.13 seconds (2542.80 MB/s) > [ 131.179817] Suspending console(s) (use no_console_suspend to debug) > [ 131.182797] sd 0:0:0:0: [sda] Synchronizing SCSI cache > [ 131.183264] HDA Intel :01:00.1: PCI INT B disabled > [ 131.183802] HDA Intel :00:1b.0: PCI INT A disabled > [ 131.504654] PM: freeze of devices complete after 323.233 msecs > [ 131.506566] PM: late freeze of devices complete after 1.904 msecs > [ 131.506773] ACPI: Preparing to enter system sleep state S4 > [ 131.531112] PM: Saving platform NVS memory > [ 131.534328] Disabling non-boot CPUs ... > [ 131.580177] CPU 1 is now offline > [ 131.622812] CPU 2 is now offline > [ 131.754363] CPU 3 is now offline > [ 131.754367] lockdep: fixing up alternatives. > [ 131.755297] Extended CMOS year: 2000 > [ 131.755468] PM: Creating hibernation image: > [ 131.908665] PM: Need to copy 86670 pages > [ 132.509928] PM: Hibernation image created (86670 pages copied) > [ 131.756026] Extended CMOS year: 2000 > [ 131.756578] microcode: CPU0 updated to revision 0xc, date = 2010-06-10 > [ 131.756606] Enabling non-boot CPUs ... > [ 131.763890] lockdep: fixing up alternatives. > [ 131.763904] Booting Node 0 Processor 1 APIC 0x1 > [ 131.763908] smpboot cpu 1: start_ip = 98000 > [ 131.881690] Switched to NOHz mode on CPU #1 > [ 131.923128] NMI watchdog enabled, takes one hw-pmu counter. > [ 131.924625] microcode: CPU1 updated to revision 0xc, date = 2010-06-10 > [ 131.924656] CPU1 is up > [ 131.924949] lockdep: fixing up alternatives. > [ 131.924959] Booting Node 0 Processor 2 APIC 0x4 > [ 131.924962] smpboot cpu 2: start_ip = 98000 > [ 132.041707] Switched to NOHz mode on CPU #2 > [ 132.083285] NMI watchdog enabled, takes one hw-pmu counter. > [ 132.084938] microcode: CPU2 updated to revision 0xc, date = 2010-06-10 > [ 132.084950] CPU2 is up > [ 132.085415] lockdep: fixing up alternatives. > [ 132.085460] Booting Node 0 Processor 3 APIC 0x5 > [ 132.085463] smpboot cpu 3: start_ip = 98000 > [ 132.201793] Switched to NOHz mode on CPU #3 > [ 132.244130] NMI watchdog enabled, takes one hw-pmu counter. > [ 132.245820] microcode: CPU3 updated to revision 0xc, date = 2010-06-10 > [ 132.245834] CPU3 is up > [ 132.248617] ACPI: Waking up from system sleep state S4 > [ 132.324868] PM: early thaw of devices complete after 0.540 msecs > [ 132.325292] pci :00:1e.0: setting latency timer to 64 > [ 132.325386] radeon :01:00.0: power state changed by ACPI to D0 > [ 132.325470] ahci :00:1f.2: restoring config space at offset 0x1 (was > 0x2b00403, writing 0x2b00407) > [ 132.325510] radeon :01:00.0: power state changed by ACPI to D0 > [ 132.325547] ahci :00:1f.2: setting latency timer to 64 > [ 132.325630] radeon :01:00.0: setting latency timer to 64 > [ 132.325681] sd 0:0:0:0: [sda] Starting disk > [ 132.338376] HDA Intel :00:1b.0: BAR 0: set to [mem > 0xb410-0xb4103fff 64bit] (PCI address [0xb410-0xb4103fff]) > [ 132.338381] HDA Intel :01:00.1: BAR 0: set to [mem > 0xb402-0xb4023fff 64bit] (PCI address [0xb402-0xb4023fff]) > [ 132.338413] HDA Intel :00:1b.0: restoring config space at offset 0xf > (was 0x100, writing 0x10a) > [ 132.338457] HDA Intel :00:1b.0: restoring config space at offset 0x3 > (was 0x0, writing 0x10) > [ 132.338470] HDA Intel :00:1b.0: restoring config space at offset 0x1 > (was 0x10, writing 0x12) > [ 132.338501] HDA Intel :01:00.1: PCI INT B -> GSI 17 (level, low) -> > IRQ 17 > [ 132.338511] HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> > IRQ 22 > [ 132.338514] HDA Intel :01:00.1: setting latency timer to 64 > [ 132.338522] HDA Intel :00:1b.0: setting latency timer to 64 > [ 132.338612] HDA Intel :00:1b.0: irq 43 for MSI/MSI-X > [ 132.338615] HDA Intel :0
[Bug 35998] Artifacts under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #4 from Milan Plzik 2011-04-11 15:20:55 PDT --- Created an attachment (id=45494) --> (https://bugs.freedesktop.org/attachment.cgi?id=45494) glxinfo output Same happens to me, lspci output is: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Xpress 1250 hardware is Dell Latitude XT. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 Andrew Morton changed: What|Removed |Added CC||akpm at linux-foundation.org Component|Video(Other)|Video(DRI - non Intel) AssignedTo|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 Rafael J. Wysocki changed: What|Removed |Added CC||florian at mickler.org, ||maciej.rutecki at gmail.com, ||rjw at sisk.pl Blocks||32012 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2011-04-11 23:14:27 --- Is this a regression? Did previous kernels work ok? If so, can you bisect? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 32982] Kernel locks up a few minutes after boot
https://bugzilla.kernel.org/show_bug.cgi?id=32982 --- Comment #2 from Alex Deucher 2011-04-11 23:15:20 --- Does it work ok if you remove: vga=0x31a nomodesetting from your grub entry? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33867] [bisected] Graphics corruption related to pageflip ioctl support in 2.6.38-rc*
https://bugs.freedesktop.org/show_bug.cgi?id=33867 --- Comment #14 from Dave Witbrodt 2011-04-11 19:59:28 PDT --- I did no further testing after the onset of the Japan crisis, but I have just started updating some relevant parts of my system. Updating from kernel 2.6.38-rc8 to 2.6.38.2 did not seem to have an effect, but updating Mesa to 7.11.0-devel (commit a26121f3) changed the observed behavior in prboom-plus. The black melts are gone, replaced by transient graphics corruption when starting a new game. This corruption fades within a span of about 1 second, and causes no further problems. In short, it looks like the problem was a combination of kernel changes and Mesa support for my Radeon HD 5750. Apparently some changes to Mesa over the past 7 weeks have resolved the problem I was originally reporting here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34156] r600g performance regression between 780c183b and 862ebb41
https://bugs.freedesktop.org/show_bug.cgi?id=34156 --- Comment #9 from Dave Witbrodt 2011-04-11 20:15:22 PDT --- I have been away from Linux and testing radeon support since the Japan crisis began. Updating to Mesa 7.11.0-devel, commit a26121f3, caused the same slowdown I had observed before: min/max framerate in 'torcs' dropped from 28/54 fps to 17/34 fps. I was planning on restoring local packages of my last fast-working Mesa, but decided to rebuild my entire X stack against my newly updated kernel (updated from 2.6.38-rc8 to 2.6.38.2). To my shock, I found that replacing xorg-server 1.9.99.903 with 1.10.0.902 and updating the radeon driver to the latest git version, 6.14.99-devel, commit cc7d1fa3 -- both built against the Mesa mentioned above -- improved Mesa performance in 'torcs' dramatically. It is no longer as consistently high as I was getting, but gives me 17/54 fps. I also notice that another test program, 'prboom-plus', has dramatically improved performance all around. As a result, I am abandoning my local git branch where I intended to pin down the exact cause of the performance changes -- I haven't touch it for 7 weeks anyway -- and start following the Mesa HEAD again. Sorry for the false alarm. It appears that Mesa changes alone were not to blame for whatever performance problems I was experiencing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34493] r600g performance regression introduced by 467023e8 (Marek Olšák: r600g: use the same upload buffer for vertices, indices, and constants)
https://bugs.freedesktop.org/show_bug.cgi?id=34493 --- Comment #7 from Dave Witbrodt 2011-04-11 20:15:46 PDT --- I have been away from Linux and testing radeon support since the Japan crisis began. Updating to Mesa 7.11.0-devel, commit a26121f3, caused the same slowdown I had observed before: min/max framerate in 'torcs' dropped from 28/54 fps to 17/34 fps. I was planning on restoring local packages of my last fast-working Mesa, but decided to rebuild my entire X stack against my newly updated kernel (updated from 2.6.38-rc8 to 2.6.38.2). To my shock, I found that replacing xorg-server 1.9.99.903 with 1.10.0.902 and updating the radeon driver to the latest git version, 6.14.99-devel, commit cc7d1fa3 -- both built against the Mesa mentioned above -- improved Mesa performance in 'torcs' dramatically. It is no longer as consistently high as I was getting, but gives me 17/54 fps. I also notice that another test program, 'prboom-plus', has dramatically improved performance all around. As a result, I am abandoning my local git branch where I intended to pin down the exact cause of the performance changes -- I haven't touch it for 7 weeks anyway -- and start following the Mesa HEAD again. Sorry for the false alarm. It appears that Mesa changes alone were not to blame for whatever performance problems I was experiencing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
