[Bug 25741] [R600/KMS] external display flickering
http://bugs.freedesktop.org/show_bug.cgi?id=25741 --- Comment #13 from Luca Tettamanti kronos...@gmail.com 2009-12-29 02:48:46 PST --- (In reply to comment #12) Created an attachment (id=32336) -- (http://bugs.freedesktop.org/attachment.cgi?id=32336) [details] add missing breaks This patch should fix it. The EDID is back, the flickering is still there, but I think I see the problem. The old code used id as offset into the asSS_Info array; now this is the PPLL_SS_Info table on my M76: data_table ae26 #12 (PPLL_SS_Info): Size 000c Format Rev. 01 Param Rev. 00 Content Rev. 02 :1e00 0101 2a01 0202 *... : ATOM_COMMON_TABLE_HEADER sHeader: : USHORT usStructureSize = 0x000c (12) 0002: UCHAR ucTableFormatRevision = 0x01 (1) 0003: UCHAR ucTableContentRevision= 0x02 (2) 0004: ATOM_SPREAD_SPECTRUM_ASSIGNMENT asSS_Info [0] : 0004: USHORT usSpreadSpectrumPercentage = 0x001e (30) 0006: UCHAR ucSpreadSpectrumType = 0x01 (1) 0007: UCHAR ucSS_Step = 0x01 (1) 0008: UCHAR ucSS_Delay= 0x2a (42) 0009: UCHAR ucSS_Id = 0x01 (1) 000a: UCHAR ucRecommandedRef_Div = 0x02 (2) 000b: UCHAR ucSS_Range= 0x02 (2) [cut] Note that the size is 12 bytes, so there's only one ATOM_SPREAD_SPECTRUM_ASSIGNMENT; ucSS_Id in the LVDS block is 0x1 and the old code ended up reading past the end of array. For example now it's trying to set: [ 37.652741] usSpreadSpectrumPercentage = 0xf8 [ 37.652783] ucSpreadSpectrumType = 0x1 [ 37.652824] ucSS_Step = 0x2 [ 37.652867] ucSS_Delay = 0xf [ 37.652910] ucSS_Range = 0x0 [ 37.652953] ucRecommendedRef_Div = 0x3c I guess that atombios validates the data and discards it. The new code picks up the correct data... and causes flickering. Why is this causing flickering on the _external_ display? I'm not sure what happens at boot when the outputs are cloned, but with X running the outputs are uncloned and are using different CRTCs; the kernel module enables SS on CRTC 1, and xrandr reports that it's used by LVDS. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14938] New: Unable to handle kernel paging request in radeon_fence_signaled
http://bugzilla.kernel.org/show_bug.cgi?id=14938 Summary: Unable to handle kernel paging request in radeon_fence_signaled Product: Drivers Version: 2.5 Kernel Version: 2.6.33-rc2 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: r...@sisk.pl Blocks: 14885 Regression: Yes Subject: 2.6.33-rc2: BUG: unable to handle kernel paging request at 13d8, IP=radeon_fence_signaled+0x16/0xc0 Submitter : Grant Wilson grant.wil...@zen.co.uk Date : 2009-12-27 13:40 References : http://marc.info/?l=linux-kernelm=126192123104047w=4 Notify-Also : DRI dri-devel@lists.sourceforge.net This entry is being used for tracking a regression from 2.6.32. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14945] Colors are too bright with KMS on Radeon 9xxx
http://bugzilla.kernel.org/show_bug.cgi?id=14945 --- Comment #2 from Samuel Lidén Borell sam...@slbdata.se 2009-12-29 14:21:43 --- Created an attachment (id=24346) -- (http://bugzilla.kernel.org/attachment.cgi?id=24346) Output from radeontool regs with KMS disabled and enabled Here's the output from radeontool regs with KMS disabled and enabled, respective. As you can see there are a few registers that differ: -RADEON_DAC_MACRO_CNTL0808 +RADEON_DAC_MACRO_CNTL -RADEON_TV_DAC_CNTL0740 +RADEON_TV_DAC_CNTL07780142 -RADEON_CRTC_EXT_CNTL8040 +RADEON_CRTC_EXT_CNTL0d008040 Maybe this is somehow related to this bug? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14945] Colors are too bright with KMS on Radeon 9xxx
http://bugzilla.kernel.org/show_bug.cgi?id=14945 --- Comment #1 from Samuel Lidén Borell sam...@slbdata.se 2009-12-29 13:46:05 --- Created an attachment (id=24345) -- (http://bugzilla.kernel.org/attachment.cgi?id=24345) Output from dmesg -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14945] New: Colors are too bright with KMS on Radeon 9xxx
http://bugzilla.kernel.org/show_bug.cgi?id=14945 URL: https://bugzilla.redhat.com/show_bug.cgi?id=505903 Summary: Colors are too bright with KMS on Radeon 9xxx Product: Drivers Version: 2.5 Kernel Version: 2.6.32 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: sam...@slbdata.se Regression: No Created an attachment (id=24344) -- (http://bugzilla.kernel.org/attachment.cgi?id=24344) Test case The colors on my monitor are too bright when KMS is enabled, both in the console and in Xorg. I have a Radeon 9500 PRO, but Radeon 9000 is also affected[1]. I've attached a script to test the behavior in the console. It should display a gradient with yellow colors, and all colors should be distinguishable (except possibly the first two depending on the monitor settings). With KMS enabled, the colors are too bright and all but the last two are indistinguishable. I'm using Ubuntu 10.04 (alpha version with latest upgrades) with this kernel: Linux crashie2 2.6.32-9-generic #13-Ubuntu SMP Thu Dec 17 17:02:51 UTC 2009 i686 GNU/Linux [1] https://bugzilla.redhat.com/show_bug.cgi?id=505903 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
2.6.33-rc2: Reported regressions 2.6.31 - 2.6.32
[NOTES: * I really hope that at least _some_ of the bugs below have been already fixed, but I didn't have the time to search through all of the histories. _Please_ let me know which of them can be closed. * If you close one of the bugs in this list, please do your best to put the hash of the fix commit into the Bugzilla entry.] This message contains a list of some regressions introduced between 2.6.31 and 2.6.32, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions introduced between 2.6.31 and 2.6.32, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2009-12-29 124 60 57 2009-11-21 86 29 25 2009-11-16 84 46 41 2009-10-26 66 42 37 2009-10-12 48 31 27 2009-10-02 22 15 9 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14943 Subject : nfs regression? Submitter : Nikola Ciprich extmaill...@linuxbox.cz Date: 2009-12-28 12:10 (2 days old) References : http://marc.info/?l=linux-kernelm=126200276223524w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14939 Subject : drm: random hang with i915 Submitter : Arnd Bergmann a...@arndb.de Date: 2009-12-07 17:30 (23 days old) References : http://marc.info/?l=linux-kernelm=126020704125723w=4 Handled-By : Jesse Barnes jbar...@virtuousgeek.org Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14933 Subject : OOM killer unexpectedly called Submitter : A. Boulan arnaud.bou...@libertysurf.fr Date: 2009-12-24 23:42 (6 days old) References : http://marc.info/?l=linux-kernelm=126169821317492w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14922 Subject : 2.6.32 seemed to have broken nVidia MCP7A sata controller Submitter : Mike Cui cui...@gmail.com Date: 2009-12-19 6:13 (11 days old) References : http://marc.info/?l=linux-idem=126120323407742w=4 Handled-By : Jeff Garzik j...@garzik.org Robert Hancock hancock...@gmail.com Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14905 Subject : kernel BUG at kernel/timer.c:951! Submitter : Bernard Pidoux bernard.pid...@upmc.fr Date: 2009-12-19 13:38 (11 days old) References : http://marc.info/?l=linux-kernelm=126122997831460w=4 Handled-By : Jarek Poplawski jark...@gmail.com Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14903 Subject : Kernel panic - not syncing: Attempted to kill init! Submitter : Zhiyong Wu zwu.ker...@gmail.com Date: 2009-12-18 4:08 (12 days old) References : http://marc.info/?l=linux-kernelm=126110931124738w=4 Handled-By : Américo Wang xiyou.wangc...@gmail.com Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14902 Subject : Boot ends not on tty1 Submitter : Andreas Friedrich andreas.friedr...@ts.fujitsu.com Date: 2009-12-15 8:05 (15 days old) References : http://marc.info/?l=linux-kernelm=126086495304263w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14898 Subject : ksoftirqd problem Submitter : Nico segfau...@hotmail.com Date: 2009-12-13 19:05 (17 days old) References : http://marc.info/?l=linux-kernelm=126073114325690w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14897 Subject : i915: Commit 0e442c60 causes flickering Submitter : David John david...@xenontk.org Date: 2009-12-09 17:26 (21 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0e442c60dd39ac6924b11a20497734bd2303744c References : http://marc.info/?l=linux-kernelm=126037889600769w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14896 Subject : REGRESSION for RT2561/RT61 in 2.6.32, related to power saving Submitter : Alan Stern st...@rowland.harvard.edu Date: 2009-12-06 22:12 (24 days old) References : http://marc.info/?l=linux-kernelm=126013756829691w=4 Handled-By : Gertjan van Wingerde gwinge...@gmail.com Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14895 Subject : BUG in kernel 2.6.32 when using luks encrypted root and RAID0.. Submitter : r4 m...@centrum.cz Date: 2009-12-03 18:24 (27 days old) References
2.6.33-rc2: Reported regressions from 2.6.32
[NOTES: * There you go, another round of tracking regressions. It's not too bad at the moment, as far as the regressions from 2.6.32 are concerned, but we have quite a few -stable regressions, apparently in the DRI area. * Regressions from 2.6.31 are still being reported.] This message contains a list of some regressions from 2.6.32, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.32, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2009-12-29 36 34 27 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14952 Subject : instant reboot on loading 2.6.33-rc on Celeron 900 Submitter : Meelis Roos mr...@linux.ee Date: 2009-12-29 13:57 (1 days old) References : http://marc.info/?l=linux-kernelm=126209508500393w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950 Subject : tbench regression with 2.6.33-rc1 Submitter : Lin Ming ming.m@intel.com Date: 2009-12-25 11:11 (5 days old) References : http://marc.info/?l=linux-kernelm=126174044213172w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected Submitter : Borislav Petkov petko...@googlemail.com Date: 2009-12-26 9:45 (4 days old) References : http://marc.info/?l=linux-kernelm=126182073616279w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 Subject : EHCI resume sysfs duplicates Submitter : Borislav Petkov petko...@googlemail.com Date: 2009-12-26 9:36 (4 days old) References : http://marc.info/?l=linux-kernelm=126182020615709w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14947 Subject : Blank screen for Intel KMS Submitter : Miguel Calleja mcalle...@telecable.es Date: 2009-12-25 13:10 (5 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fc816655236cd9da162356e96e74c7cfb0834d92 References : http://marc.info/?l=linux-kernelm=126174693019098w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce sbo...@blueyonder.co.uk Date: 2009-12-23 16:55 (7 days old) References : http://marc.info/?l=linux-kernelm=126158734326801w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 Subject : gkrellm no longer shows all the temperatures on thinkpad x60 Submitter : Pavel Machek pa...@ucw.cz Date: 2009-12-27 21:57 (3 days old) References : http://marc.info/?l=linux-kernelm=126195107005565w=4 Handled-By : Henrique de Moraes Holschuh h...@hmh.eng.br Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14940 Subject : cfq-iosched: tiobench regression Submitter : Shaohua Li shaohua...@intel.com Date: 2009-12-24 0:55 (6 days old) References : http://marc.info/?l=linux-kernelm=126161612401994w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14938 Subject : Unable to handle kernel paging request in radeon_fence_signaled Submitter : Grant Wilson grant.wil...@zen.co.uk Date: 2009-12-27 13:40 (3 days old) References : http://marc.info/?l=linux-kernelm=126192123104047w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937 Subject : WARNING: at kernel/lockdep.c:2830 Submitter : Grant Wilson grant.wil...@zen.co.uk Date: 2009-12-27 13:35 (3 days old) References : http://marc.info/?l=linux-kernelm=126192220404829w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14936 Subject : kernel BUG at fs/ext4/inode.c:1063 if attempted to use non-ext4 partition with ext4 Submitter : Gene Heskett gene.hesk...@verizon.net Date: 2009-12-26 14:13 (4 days old) References : http://marc.info/?l=linux-kernelm=126183682330809w=4 http://marc.info/?l=linux-kernelm=126169372613898w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14934 Subject : kernel crash during boot Submitter : werner w.landg...@ru.ru Date: 2009-12-25 5:37 (5 days old) References : http://marc.info/?l=linux-kernelm=126171951030608w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14925
[Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected Submitter : Borislav Petkov petko...@googlemail.com Date: 2009-12-26 9:45 (4 days old) References : http://marc.info/?l=linux-kernelm=126182073616279w=4 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/29 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com
wrote:
Unless there are more subtleties all is needed it to enabled the
interrupt and catch it in r600_irq_process.
That's pretty much it. Pre-r6xx asics have a GUI interrupt as well.
I can look up the details for that if they are not already documented.
I can't find a way to ack the interrupt; I see
RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards,
right?
You don't have to ACK it as the CP generates the interrupt in
software; similar to the sw interrupts used for fences.
Ok, good: I've got the stub running on my M76. r100 and rs600 parts are
untested. Comments?
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
[...]
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r100.c 2009-12-28
22:30:59.079748392 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r100.c 2009-12-28
22:41:07.803741755 +0100
@@ -246,6 +246,9 @@
if (rdev-irq.sw_int) {
tmp |= RADEON_SW_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ tmp |= RADEON_GUI_IDLE_INT_ENABLE;
+ }
if (rdev-irq.crtc_vblank_int[0]) {
tmp |= RADEON_CRTC_VBLANK_MASK;
}
@@ -278,7 +281,8 @@
uint32_t irqs = RREG32(RADEON_GEN_INT_STATUS);
uint32_t irq_mask = RADEON_SW_INT_TEST |
RADEON_CRTC_VBLANK_STAT | RADEON_CRTC2_VBLANK_STAT |
- RADEON_FP_DETECT_STAT | RADEON_FP2_DETECT_STAT;
+ RADEON_FP_DETECT_STAT | RADEON_FP2_DETECT_STAT |
+ RADEON_GUI_IDLE_INT_TEST_ACK;
if (irqs) {
WREG32(RADEON_GEN_INT_STATUS, irqs);
@@ -318,6 +322,9 @@
queue_hotplug = true;
DRM_DEBUG(HPD2\n);
}
+ if (status RADEON_GUI_IDLE_INT_TEST_ACK) {
+ DRM_DEBUG(GUI idle\n);
+ }
You'll need to ack this on pre-r6xx.
Clear on write? I've included the relevant bit in irq_mask, so r100
should be ok.
Right. missed that. should be ok.
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/rs600.c 2009-12-28
22:32:30.927884090 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/rs600.c 2009-12-28
22:46:23.211897501 +0100
@@ -318,6 +318,9 @@
if (rdev-irq.sw_int) {
tmp |= S_40_SW_INT_EN(1);
}
+ if (rdev-irq.idle_int) {
+ tmp |= S_40_GUI_IDLE(1);
+ }
if (rdev-irq.crtc_vblank_int[0]) {
mode_int |= S_006540_D1MODE_VBLANK_INT_MASK(1);
}
@@ -411,6 +414,9 @@
queue_hotplug = true;
DRM_DEBUG(HPD2\n);
}
+ if (G_44_GUI_IDLE_STAT(status)) {
+ DRM_DEBUG(GUI idle\n);
+ }
You'll need to ACK this on pre-r6xx chips.
Ok, I was mislead by the name of the file ;-)
rs600 = sort-of-r500?
yes. rs600 (and rs690/rs740) have avivo display engines, but r4xx 3d
engines. The irq stuff is the same as r5xx.
Alex
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14331] Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off
http://bugzilla.kernel.org/show_bug.cgi?id=14331 --- Comment #13 from Rafael J. Wysocki r...@sisk.pl 2009-12-29 16:19:52 --- On Tuesday 29 December 2009, Alex Villacís Lasso wrote: El 29/12/09 10:28, Rafael J. Wysocki escribió: This message has been generated automatically as a part of a report of regressions introduced between 2.6.31 and 2.6.32. The following bug entry is on the current list of known regressions introduced between 2.6.31 and 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14331 Subject : Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off Submitter : Alex Villacis Lassoavill...@ceibo.fiec.espol.edu.ec Date: 2009-10-06 00:29 (85 days old) I will not be able to test this regression anymore. I recently switched to Fedora 12 on the target machine, and of course the userspace works with the distro kernel. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14331] Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off
http://bugzilla.kernel.org/show_bug.cgi?id=14331 Rafael J. Wysocki r...@sisk.pl changed: What|Removed |Added Status|NEW |RESOLVED Resolution||UNREPRODUCIBLE -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14331] Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off
http://bugzilla.kernel.org/show_bug.cgi?id=14331 Rafael J. Wysocki r...@sisk.pl changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14945] Colors are too bright with KMS on Radeon 9xxx
http://bugzilla.kernel.org/show_bug.cgi?id=14945 --- Comment #3 from Alex Deucher alexdeuc...@gmail.com 2009-12-29 17:08:01 --- Created an attachment (id=24351) -- (http://bugzilla.kernel.org/attachment.cgi?id=24351) fix primary dac adj values This patch should fix it. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: add primary dac adj values table
From a71f0302835876038fb608e0d7a570dc3a0f145c Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 29 Dec 2009 12:09:17 -0500
Subject: [PATCH] drm/radeon/kms: add primary dac adj values table
Look up primary dac adj values from the table if
there is no bios or bios dac table to reference.
The lookup table may need to be adjusted for certain
families.
Should fix kernel bug 14945.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_combios.c | 50 +-
1 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 1204234..7018f32 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -595,6 +595,34 @@ bool radeon_combios_get_clock_info(struct drm_device *dev)
return false;
}
+static const uint32_t default_primarydac_adj[CHIP_LAST] = {
+ 0x0808, /* r100 */
+ 0x0808, /* rv100 */
+ 0x0808, /* rs100 */
+ 0x0808, /* rv200 */
+ 0x0808, /* rs200 */
+ 0x0808, /* r200 */
+ 0x0808, /* rv250 */
+ 0x, /* rs300 */
+ 0x0808, /* rv280 */
+ 0x0808, /* r300 */
+ 0x0808, /* r350 */
+ 0x0808, /* rv350 */
+ 0x0808, /* rv380 */
+ 0x0808, /* r420 */
+ 0x0808, /* r423 */
+ 0x0808, /* rv410 */
+ 0x, /* rs400 */
+ 0x, /* rs480 */
+};
+
+static void radeon_legacy_get_primary_dac_info_from_table(struct
radeon_device *rdev,
+ struct
radeon_encoder_primary_dac *p_dac)
+{
+ p_dac-ps2_pdac_adj = default_primarydac_adj[rdev-family];
+ return;
+}
+
struct radeon_encoder_primary_dac *radeon_combios_get_primary_dac_info(struct
radeon_encoder
*encoder)
@@ -604,20 +632,20 @@ struct radeon_encoder_primary_dac
*radeon_combios_get_primary_dac_info(struct
uint16_t dac_info;
uint8_t rev, bg, dac;
struct radeon_encoder_primary_dac *p_dac = NULL;
+ int found = 0;
- if (rdev-bios == NULL)
+ p_dac = kzalloc(sizeof(struct radeon_encoder_primary_dac),
+ GFP_KERNEL);
+
+ if (!p_dac)
return NULL;
+ if (rdev-bios == NULL)
+ goto out;
+
/* check CRT table */
dac_info = combios_get_table_offset(dev, COMBIOS_CRT_INFO_TABLE);
if (dac_info) {
- p_dac =
- kzalloc(sizeof(struct radeon_encoder_primary_dac),
- GFP_KERNEL);
-
- if (!p_dac)
- return NULL;
-
rev = RBIOS8(dac_info) 0x3;
if (rev 2) {
bg = RBIOS8(dac_info + 0x2) 0xf;
@@ -628,9 +656,13 @@ struct radeon_encoder_primary_dac
*radeon_combios_get_primary_dac_info(struct
dac = RBIOS8(dac_info + 0x3) 0xf;
p_dac-ps2_pdac_adj = (bg 8) | (dac);
}
-
+ found = 1;
}
+out:
+ if (!found) /* fallback to defaults */
+ radeon_legacy_get_primary_dac_info_from_table(rdev, p_dac);
+
return p_dac;
}
--
1.5.6.3
0001-drm-radeon-kms-add-primary-dac-adj-values-table.patch
Description: application/mbox
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev --
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com
wrote:
On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com
wrote:
W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
It may be that the engine doesn't like to be reclocked while it's
running. Perhaps we should use the GUI idle interrupt rather than
vblanks to reclock the engine.
Could you say something more about GUI idle interrupt, please?
It's mentioned in the documentation of the IH (see r600.c); I guess
it's enabled by GUI_IDLE_INT_ENABLE.
What is this, do we already have code for that?
Unless there are more subtleties all is needed it to enabled the
interrupt and catch it in r600_irq_process.
That's pretty much it. Pre-r6xx asics have a GUI interrupt as well.
I can look up the details for that if they are not already documented.
I can't find a way to ack the interrupt; I see
RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards,
right?
You don't have to ACK it as the CP generates the interrupt in
software; similar to the sw interrupts used for fences.
Ok, good: I've got the stub running on my M76. r100 and rs600 parts are
untested. Comments?
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
I've adapted Rafał's patch to do the reclock when the idle interrupt is
fired (which btw should take care of the special case for nr CRTCs 1).
Unfortunately I still see the black frame when reclocking is performed.
So I tried recloking directly from the IH (yeah, I'm ashamed of
myself...); this got rid of the black frame, but causes corruption of a
horizontal block of the screen (during the reclock, before and after the
screen looks fine). In this second case I've added a spinlock to guard
the access to the CP ring, so nothing touches it while reclocking is
performed; however by the time we process the idle interrupt -
especially considering that multiple events might be queued in the IH
ring - someone else (i.e. one of the other cores) might already have
submitted more work; what do you think?
I'm attaching 3 patches; the first one contains the stub idle IH, the
second one is Rafał's patch adapted for idle interrupt (it's not very
polished), the third one moves reclocking to IH (and as is it's just an
ugly hack).
Luca
--
In linea di principio sarei indifferente al natale, se solo il natale
ricambiasse la cortesia e mi lasciasse in pace. -- Marco d'Itri
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r600.c 2009-12-28 16:38:38.388825742 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r600.c 2009-12-28 22:03:12.936157804 +0100
@@ -2458,6 +2458,7 @@
int r600_irq_set(struct radeon_device *rdev)
{
u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
+ u32 grbm_int_cntl;
u32 mode_int = 0;
u32 hpd1, hpd2, hpd3, hpd4 = 0, hpd5 = 0, hpd6 = 0;
@@ -2465,6 +2466,8 @@
if (!rdev-ih.enabled)
return 0;
+ grbm_int_cntl = RREG32(GRBM_INT_CNTL) ~GUI_IDLE_INT_ENABLE;
+
if (ASIC_IS_DCE3(rdev)) {
hpd1 = RREG32(DC_HPD1_INT_CONTROL) ~DC_HPDx_INT_EN;
hpd2 = RREG32(DC_HPD2_INT_CONTROL) ~DC_HPDx_INT_EN;
@@ -2484,6 +2487,10 @@
DRM_DEBUG(r600_irq_set: sw int\n);
cp_int_cntl |= RB_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ DRM_DEBUG(r600_irq_set: GUI idle int\n);
+ grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
+ }
if (rdev-irq.crtc_vblank_int[0]) {
DRM_DEBUG(r600_irq_set: vblank 0\n);
mode_int |= D1MODE_VBLANK_INT_MASK;
@@ -2518,6 +2525,7 @@
}
WREG32(CP_INT_CNTL, cp_int_cntl);
+ WREG32(GRBM_INT_CNTL, grbm_int_cntl);
WREG32(DxMODE_INT_MASK, mode_int);
if (ASIC_IS_DCE3(rdev)) {
WREG32(DC_HPD1_INT_CONTROL, hpd1);
@@ -2806,6 +2814,9 @@
case 181: /* CP EOP event */
DRM_DEBUG(IH: CP EOP\n);
break;
+ case 233: /* GUI idle event */
+ DRM_DEBUG(IH: GUI idle\n);
+ break;
default:
DRM_ERROR(Unhandled interrupt: %d %d\n, src_id, src_data);
break;
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon.h 2009-12-28 16:38:13.945836481 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon.h 2009-12-28 22:02:48.964001788 +0100
@@ -343,6 +343,7 @@
struct radeon_irq {
bool installed;
bool sw_int;
+ bool idle_int;
/* FIXME: use a define max crtc rather than hardcode it */
bool crtc_vblank_int[2];
/* FIXME: use defines for max hpd/dacs */
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28 16:37:10.669823739 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon_irq_kms.c
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: I've adapted Rafał's patch to do the reclock when the idle interrupt is fired (which btw should take care of the special case for nr CRTCs 1). Unfortunately I still see the black frame when reclocking is performed. So I tried recloking directly from the IH (yeah, I'm ashamed of myself...); this got rid of the black frame, but causes corruption of a horizontal block of the screen (during the reclock, before and after the screen looks fine). In this second case I've added a spinlock to guard the access to the CP ring, so nothing touches it while reclocking is performed; however by the time we process the idle interrupt - especially considering that multiple events might be queued in the IH ring - someone else (i.e. one of the other cores) might already have submitted more work; what do you think? Maybe a spinlock doesn't cut it. How about some mutex you take when you need to reclock, to let tasks trying to add to the CP ring just sleep, and then you unmask the idle interrupt. When you receive the idle interrupt, you reclock, you free the mutex, and voilà. Xav -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.33-rc2: Reported regressions from 2.6.32
2009/12/29 Rafael J. Wysocki r...@sisk.pl: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14910 Subject : Stable version 2.6.32.2 broke my KMS Radeon setup Submitter : Ruud Linders kerne...@xs4all.nl Date : 2009-12-20 12:02 (10 days old) References : http://marc.info/?l=linux-kernelm=126131105608871w=4 Has patch (I think it was even submitted to Linus). -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14910] Stable version 2.6.32.2 broke my KMS Radeon setup
http://bugzilla.kernel.org/show_bug.cgi?id=14910 Rafael J. Wysocki r...@sisk.pl changed: What|Removed |Added Blocks|14885 | --- Comment #2 from Rafael J. Wysocki r...@sisk.pl 2009-12-29 20:43:49 --- Dropping from the list of recent mainline regressions as a -stable only issue. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.33-rc2: Reported regressions from 2.6.32
On Tuesday 29 December 2009, Rafał Miłecki wrote: 2009/12/29 Rafael J. Wysocki r...@sisk.pl: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14910 Subject : Stable version 2.6.32.2 broke my KMS Radeon setup Submitter : Ruud Linders kerne...@xs4all.nl Date: 2009-12-20 12:02 (10 days old) References : http://marc.info/?l=linux-kernelm=126131105608871w=4 Has patch (I think it was even submitted to Linus). This is a -stable only issue in fact, so I'm not going to track it from now on. Please watch the next -stable announcement from Greg and remind him about this issue if the patch isn't there. Rafael -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14956] New: with KMS: kernel lockup on xorg start
http://bugzilla.kernel.org/show_bug.cgi?id=14956 Summary: with KMS: kernel lockup on xorg start Product: Drivers Version: 2.5 Kernel Version: 2.6.33-rc2 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: cstrae...@gmail.com Regression: No Created an attachment (id=24358) -- (http://bugzilla.kernel.org/attachment.cgi?id=24358) regs after virgin modprobe radeon modeset=1 before xorg start system freeze i use the latest git xorg-radeon / libdrm / mesa versions. this is reproducible behavior on my Ati Mobility Radon 3450 (Vaio laptop): 1) When booting with radeon.modeset=1 the system freezes while starting up xorg (nothing is even logged to xorg.0.log) 2) When booting with radeon.modeset=0 xorg starts and everything works 3) when booting with radeon.modeset=0 into *text mode*, and then reloading the radeon kernelmodul with modeset=1 xorg starts without problems 4) when booting with radeon.modeset=0 into *xorg*, and then stopping xorg and reloading the radeon kernelmodul with modeset=1 the system freezes even during modprobe attached are the radeontool/avivotool regs before xorg start for version 1 and 2. unfortunately the regs between version 2 and 3 don't differ and since version 4 crashes during modprobe i cant't provide a meaningful dump either -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14956] with KMS: kernel lockup on xorg start
http://bugzilla.kernel.org/show_bug.cgi?id=14956 --- Comment #1 from cstrae...@gmail.com 2009-12-29 20:51:34 --- Created an attachment (id=24359) -- (http://bugzilla.kernel.org/attachment.cgi?id=24359) radeon regs after virgin modprobe radeon modeset=1 before xorg start system freeze -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14956] with KMS: kernel lockup on xorg start
http://bugzilla.kernel.org/show_bug.cgi?id=14956 --- Comment #2 from cstrae...@gmail.com 2009-12-29 20:54:07 --- Created an attachment (id=24360) -- (http://bugzilla.kernel.org/attachment.cgi?id=24360) radeon regs after virgin modprobe radeon modeset=0 before working xorg start -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14956] with KMS: kernel lockup on xorg start
http://bugzilla.kernel.org/show_bug.cgi?id=14956 --- Comment #3 from cstrae...@gmail.com 2009-12-29 20:55:24 --- Created an attachment (id=24361) -- (http://bugzilla.kernel.org/attachment.cgi?id=24361) avivo regs after virgin modprobe radeon modeset=0 before working xorg start -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14956] with KMS: kernel lockup on xorg start
http://bugzilla.kernel.org/show_bug.cgi?id=14956 cstrae...@gmail.com changed: What|Removed |Added Attachment #24358|regs after virgin modprobe |avivo regs after virgin description|radeon modeset=1 before|modprobe radeon modeset=1 |xorg start system freeze|before xorg start system ||freeze -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14945] Colors are too bright with KMS on Radeon 9xxx
http://bugzilla.kernel.org/show_bug.cgi?id=14945 --- Comment #4 from Samuel Lidén Borell sam...@slbdata.se 2009-12-29 21:17:58 --- No, I still have the same problem with your patch (tried it with both the Ubuntu DRM modules and the latest modules in Linus' tree). And the radeontool regs still have the same values. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14945] Colors are too bright with KMS on Radeon 9xxx
http://bugzilla.kernel.org/show_bug.cgi?id=14945 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #5 from Alex Deucher alexdeuc...@gmail.com 2009-12-29 21:42:42 --- Can you attach a copy of your video bios? (as root): cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14956] with KMS: kernel lockup on xorg start
http://bugzilla.kernel.org/show_bug.cgi?id=14956 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher alexdeuc...@gmail.com 2009-12-29 21:45:40 --- Please attach your xorg log and dmesg. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14945] Colors are too bright with KMS on Radeon 9xxx
http://bugzilla.kernel.org/show_bug.cgi?id=14945 --- Comment #6 from Samuel Lidén Borell sam...@slbdata.se 2009-12-29 21:49:21 --- Created an attachment (id=24362) -- (http://bugzilla.kernel.org/attachment.cgi?id=24362) Dump of VGA BIOS -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.33-rc2: Reported regressions 2.6.31 - 2.6.32
On Tuesday 29 December 2009, Jarek Poplawski wrote: Rafael J. Wysocki wrote, On 12/29/2009 04:26 PM: ... Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14794 Subject : IP address assigned by DHCP is dropped after ~40 seconds Submitter : Márton Németh nm...@freemail.hu Date: 2009-12-13 08:59 (17 days old) IMHO this bug might be considered as fixed by updating a userspace tool (KNetworkManager) - unless somebody wants to seek for the exact reason... Good, I'll gladly close it. :-) Rafael -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14945] Colors are too bright with KMS on Radeon 9xxx
http://bugzilla.kernel.org/show_bug.cgi?id=14945 Samuel Lidén Borell sam...@slbdata.se changed: What|Removed |Added Attachment #24362|Dump of VGA BIOS|Dump of video BIOS description|| -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14956] with KMS: kernel lockup on xorg start
http://bugzilla.kernel.org/show_bug.cgi?id=14956 --- Comment #5 from cstrae...@gmail.com 2009-12-29 22:08:12 --- Created an attachment (id=24363) -- (http://bugzilla.kernel.org/attachment.cgi?id=24363) xorg + dmesg working (modeset=0) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14956] with KMS: kernel lockup on xorg start
http://bugzilla.kernel.org/show_bug.cgi?id=14956 --- Comment #6 from cstrae...@gmail.com 2009-12-29 22:10:06 --- Created an attachment (id=24364) -- (http://bugzilla.kernel.org/attachment.cgi?id=24364) xorg + dmesg crash (modeset=1) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon list corruption bug in 2.6.31.9
Hi David, here is a call trace of the list corruption I am seeing with the latest Fedora kernel, 2.6.31.9-174.fc12.x86_64, on my home system with two radeon video cards: 02:00.0 VGA compatible controller: ATI Technologies Inc RV730 [FirePro V5700] 03:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] 03:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] Usually these get followed quite quickly by a kernel crash, but I got a few today that allowed me to make this nice cut'n'paste for you. I tried out the 2.6.32.2 based rawhide kernel, but of course that one did not even boot here, due to the other radeon issue :) Is there anything I can do to help narrow down the issue, or has the code been rewritten enough in 2.6.32 and 2.6.33 that I should just upgrade to .32 once that one works? [ cut here ] WARNING: at lib/list_debug.c:30 __list_add+0x68/0x81() (Not tainted) Hardware name: Precision WorkStation T3500 list_add corruption. prev-next should be next (88032dc32da0), but was 8 800ad5aa530. (prev=880292066730). Modules linked in: fuse tun netconsole configfs autofs4 max6650 coretemp sunrpc bridge stp llc ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_multipath kvm_intel kvm uinput snd_hda_codec_analog snd_ens1371 gameport snd_ac97_codec ppdev snd_hda_intel ac97_bus parport_pc snd_usb_audio pl2303 snd_hda_codec snd_seq snd_pcm snd_usb_lib snd_rawmidi snd_timer snd_seq_device snd_hwdep usbserial snd parport iTCO_wdt tg3 iTCO_vendor_support i2c_i801 dcdbas snd_page_alloc serio_raw soundcore wmi radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: microcode] Pid: 1945, comm: Xorg Not tainted 2.6.31.9-174.fc12.x86_64 #1 Call Trace: [81051710] warn_slowpath_common+0x84/0x9c [8105177f] warn_slowpath_fmt+0x41/0x43 [a004df78] ? ttm_buffer_object_init+0x338/0x361 [ttm] [81207e23] __list_add+0x68/0x81 [a007ab3d] radeon_object_create+0x1cb/0x1de [radeon] [a007a925] ? radeon_ttm_object_object_destroy+0x0/0x4d [radeon] [a008586d] radeon_gem_object_create+0x90/0xfe [radeon] [a0086e00] ? radeon_cs_ioctl+0x14a/0x19a [radeon] [a00858db] ? radeon_gem_create_ioctl+0x0/0xdf [radeon] [a0085935] radeon_gem_create_ioctl+0x5a/0xdf [radeon] [a001521f] drm_ioctl+0x237/0x2f4 [drm] [81108cc5] vfs_ioctl+0x6f/0x87 [811091d4] do_vfs_ioctl+0x47b/0x4c1 [81109270] sys_ioctl+0x56/0x79 [8141dd20] ? do_device_not_available+0x9/0xb [81011cf2] system_call_fastpath+0x16/0x1b ---[ end trace 6286fa6c2ff39104 ]--- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25733] Latest drm-radeon-testing fails to suspend
http://bugs.freedesktop.org/show_bug.cgi?id=25733 --- Comment #1 from Gavin Kinsey ga...@trollgod.org.uk 2009-12-29 16:59:18 PST --- It seems this bug only occurs when I use a 64-bit kernel. The 32-bit kernels built from the same source suspend fine. I'm using the same 32-bit userspace for both. I just tried the vanilla 2.6.33-rc2 kernel and the bug is in there too. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto: 2009/12/28 Luca Tettamanti kronos...@gmail.com: On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote: 2009/12/28 Luca Tettamanti kronos...@gmail.com: 2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? You don't have to ACK it as the CP generates the interrupt in software; similar to the sw interrupts used for fences. Ok, good: I've got the stub running on my M76. r100 and rs600 parts are untested. Comments? Looks pretty good. I've included the proper defines from the register database below and you'll need to ack the gui idle interrupts on pre-r600 chips. Now you just have to do something when you get the idle interrupt. I've adapted Rafał's patch to do the reclock when the idle interrupt is fired (which btw should take care of the special case for nr CRTCs 1). Unfortunately I still see the black frame when reclocking is performed. So I tried recloking directly from the IH (yeah, I'm ashamed of myself...); this got rid of the black frame, but causes corruption of a horizontal block of the screen (during the reclock, before and after the screen looks fine). If you mean the interrupt handler for the idle interrupt, have you tried doing it in the interrupt handler for the vblank interrupt instead? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/radeon_cp.c: fix resource leak on error
If drm_addmap() fails master_priv is leaked.
Coverity CID: 13195
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/radeon_cp.c drivers/gpu/drm/radeon/radeon_cp.c
index 0b2f9c2..06123ba 100644
--- drivers/gpu/drm/radeon/radeon_cp.c
+++ drivers/gpu/drm/radeon/radeon_cp.c
@@ -2145,6 +2145,7 @@ int radeon_master_create(struct drm_device *dev, struct
drm_master *master)
master_priv-sarea);
if (ret) {
DRM_ERROR(SAREA setup failed\n);
+ kfree(master_priv);
return ret;
}
master_priv-sarea_priv = master_priv-sarea-handle + sizeof(struct
drm_sarea);
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/radeon_device.c: move a dereference below a NULL test
If a NULL value is possible, the dereference should only occur after the
NULL test.
Coverity CID: 13335
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/radeon_device.c
drivers/gpu/drm/radeon/radeon_device.c
index 7c68480..0c51f8e 100644
--- drivers/gpu/drm/radeon/radeon_device.c
+++ drivers/gpu/drm/radeon/radeon_device.c
@@ -733,16 +733,18 @@ void radeon_device_fini(struct radeon_device *rdev)
*/
int radeon_suspend_kms(struct drm_device *dev, pm_message_t state)
{
- struct radeon_device *rdev = dev-dev_private;
+ struct radeon_device *rdev;
struct drm_crtc *crtc;
int r;
- if (dev == NULL || rdev == NULL) {
+ if (dev == NULL || dev-dev_private == NULL) {
return -ENODEV;
}
if (state.event == PM_EVENT_PRETHAW) {
return 0;
}
+ rdev = dev-dev_private;
+
/* unpin the front buffers */
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
struct radeon_framebuffer *rfb =
to_radeon_framebuffer(crtc-fb);
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: fix a couple of array index errors
There are a couple of array overruns, and some associated confusion in
the code.
This is just a wild guess at what the code should actually look like.
Coverity CID: 13305 13306
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/radeon_legacy_tv.c
drivers/gpu/drm/radeon/radeon_legacy_tv.c
index 3a12bb0..c37535a 100644
--- drivers/gpu/drm/radeon/radeon_legacy_tv.c
+++ drivers/gpu/drm/radeon/radeon_legacy_tv.c
@@ -112,6 +112,8 @@ static const uint16_t vert_timing_NTSC[] = {
0x1817,
0x21d4,
0x0002,
+ 0x,
+ 0x,
0
};
@@ -623,9 +625,9 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
}
flicker_removal = (tmp + 500) / 1000;
- if (flicker_removal 3)
- flicker_removal = 3;
- for (i = 0; i 6; ++i) {
+ if (flicker_removal 2)
+ flicker_removal = 2;
+ for (i = 0; i ARRAY_SIZE(SLOPE_limit); ++i) {
if (flicker_removal == SLOPE_limit[i])
break;
}
diff --git drivers/gpu/drm/radeon/radeon_mode.h
drivers/gpu/drm/radeon/radeon_mode.h
index 402369d..abee9a9 100644
--- drivers/gpu/drm/radeon/radeon_mode.h
+++ drivers/gpu/drm/radeon/radeon_mode.h
@@ -218,8 +218,8 @@ struct radeon_mode_info {
};
-#define MAX_H_CODE_TIMING_LEN 32
-#define MAX_V_CODE_TIMING_LEN 32
+#define MAX_H_CODE_TIMING_LEN 16
+#define MAX_V_CODE_TIMING_LEN 16
/* need to store these as reading
back code tables is excessive */
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test
If a NULL value is possible, the dereference should only occur after the
NULL test.
Coverity CID: 13338
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/radeon_irq.c
drivers/gpu/drm/radeon/radeon_irq.c
index b79ecc4..2f349a3 100644
--- drivers/gpu/drm/radeon/radeon_irq.c
+++ drivers/gpu/drm/radeon/radeon_irq.c
@@ -289,16 +289,16 @@ int radeon_irq_emit(struct drm_device *dev, void *data,
struct drm_file *file_pr
drm_radeon_irq_emit_t *emit = data;
int result;
- if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_R600)
- return -EINVAL;
-
- LOCK_TEST_WITH_RETURN(dev, file_priv);
-
if (!dev_priv) {
DRM_ERROR(called with no initialization\n);
return -EINVAL;
}
+ if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_R600)
+ return -EINVAL;
+
+ LOCK_TEST_WITH_RETURN(dev, file_priv);
+
result = radeon_emit_irq(dev);
if (DRM_COPY_TO_USER(emit-irq_seq, result, sizeof(int))) {
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.33-rc2: Reported regressions 2.6.31 - 2.6.32
On Tue, Dec 29, 2009 at 09:55:13PM +0100, Németh Márton wrote: Jarek Poplawski wrote: Rafael J. Wysocki wrote, On 12/29/2009 04:26 PM: ... Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14794 Subject: IP address assigned by DHCP is dropped after ~40 seconds Submitter : Márton Németh nm...@freemail.hu Date : 2009-12-13 08:59 (17 days old) IMHO this bug might be considered as fixed by updating a userspace tool (KNetworkManager) - unless somebody wants to seek for the exact reason... For me (I am the reporter) the problem was solved by upgrading a userspace tool, so I think the bug filed against the kernel can be closed marking that this was not really a kernel bug. Yes, let's hope author(s) of KNetworkManager would let us know if they had to change it because of the kernel error. Regards, Jarek P. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.33-rc2: Reported regressions 2.6.31 - 2.6.32
Jarek Poplawski wrote: Rafael J. Wysocki wrote, On 12/29/2009 04:26 PM: ... Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=14794 Subject : IP address assigned by DHCP is dropped after ~40 seconds Submitter: Márton Németh nm...@freemail.hu Date : 2009-12-13 08:59 (17 days old) IMHO this bug might be considered as fixed by updating a userspace tool (KNetworkManager) - unless somebody wants to seek for the exact reason... For me (I am the reporter) the problem was solved by upgrading a userspace tool, so I think the bug filed against the kernel can be closed marking that this was not really a kernel bug. Regards, Márton Németh -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.33-rc2: Reported regressions 2.6.31 - 2.6.32
Rafael J. Wysocki wrote, On 12/29/2009 04:26 PM: ... Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14794 Subject : IP address assigned by DHCP is dropped after ~40 seconds Submitter : Márton Németh nm...@freemail.hu Date : 2009-12-13 08:59 (17 days old) IMHO this bug might be considered as fixed by updating a userspace tool (KNetworkManager) - unless somebody wants to seek for the exact reason... Jarek P. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/radeon_fence.c: move a dereference below the NULL test
If a NULL value is possible, the dereference should only occur after the
NULL test.
Coverity CID: 13334
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/radeon_fence.c
drivers/gpu/drm/radeon/radeon_fence.c
index 4cdd8b4..f3a8380 100644
--- drivers/gpu/drm/radeon/radeon_fence.c
+++ drivers/gpu/drm/radeon/radeon_fence.c
@@ -140,14 +140,14 @@ int radeon_fence_create(struct radeon_device *rdev,
struct radeon_fence **fence)
bool radeon_fence_signaled(struct radeon_fence *fence)
{
- struct radeon_device *rdev = fence-rdev;
unsigned long irq_flags;
bool signaled = false;
- if (rdev-gpu_lockup) {
+ if (fence == NULL) {
return true;
}
- if (fence == NULL) {
+
+ if (fence-rdev-gpu_lockup) {
return true;
}
write_lock_irqsave(fence-rdev-fence_drv.lock, irq_flags);
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/r100.c: check for invalid family
If there is an invalid family the fw_name is NULL and causes an
NULL pointer dereference.
This just adds a check for something unexpected.
Coverity CID: 13251
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/r100.c drivers/gpu/drm/radeon/r100.c
index 7172746..e4b9770 100644
--- drivers/gpu/drm/radeon/r100.c
+++ drivers/gpu/drm/radeon/r100.c
@@ -584,6 +584,8 @@ static int r100_cp_init_microcode(struct radeon_device
*rdev)
(rdev-family == CHIP_RV570)) {
DRM_INFO(Loading R500 Microcode\n);
fw_name = FIRMWARE_R520;
+ } else {
+ return -EINVAL;
}
err = request_firmware(rdev-me_fw, fw_name, pdev-dev);
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/radeon_connectors.c: add a NULL test before dereference
The encoder variable can be NULL in this function so I believe it should
be checked before dereference.
Coverity CID: 13253
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/radeon_connectors.c
drivers/gpu/drm/radeon/radeon_connectors.c
index 2016156..b82ae61 100644
--- drivers/gpu/drm/radeon/radeon_connectors.c
+++ drivers/gpu/drm/radeon/radeon_connectors.c
@@ -615,7 +615,7 @@ static enum drm_connector_status radeon_vga_detect(struct
drm_connector *connect
ret = connector_status_connected;
}
} else {
- if (radeon_connector-dac_load_detect) {
+ if (radeon_connector-dac_load_detect encoder) {
encoder_funcs = encoder-helper_private;
ret = encoder_funcs-detect(encoder, connector);
}
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
