Bug#1034903: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin navi10_mes.bin for module amdgpu
On Wed, Jun 21, 2023 at 11:38 AM Ben Hutchings wrote:
>
> On Thu, 27 Apr 2023 15:43:28 +0800 xiao sheng wen(肖盛文）
> wrote:
> > Package: firmware-amd-graphics
> > Version: 20230310-1~exp1
> > Severity: normal
> > X-Debbugs-Cc: atzli...@sina.com
> >
> > Hi,
> >
> > When I upgrade to kernel 5.10.0-22-arm64, there are following error
> > infos:
> >
> > W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin
> > for module amdgpu
> > W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module
> > amdgpu
> [...]
Those could be dropped. They are not really used by the driver. They
are for a feature which was not ultimately productized on those parts.
>
> I see that the amdgpu driver has had references to these files for
> several years, but they've never been added to linux-firmware.git.
> More recently amdgpu added:
>
> MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes.bin");
> MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes_2.bin");
> MODULE_FIRMWARE("amdgpu/gc_11_0_3_mes1.bin");
>
> and these are also missing from linux-firmware.git.
>
> Is this firmware intended to be available to the public?
Yes, those will be available soon.
Alex
Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?
On Mon, Feb 21, 2022 at 3:29 AM Eric Valette wrote: > > On 20/02/2022 16:48, Dominique Dumont wrote: > > On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote: > >> Does the system actually suspend? > > > > Not really. The screens looks like it's going to suspend, but it does come > > back after 10s or so. The light mounted in the middle of the power button > > does > > not switch off. > > > As I have a very similar problem and also commented on the original > debian bug report > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005005), I will add > some information here on another amd only laptop (renoir AMD Ryzen 7 > 4800H with Radeon Graphics + Radeon RX 5500/5500M / Pro 5500M). > > For me the suspend works once, but after the first resume (I do know > know if it is in the suspend path or the resume path I see a RIP in the > dmesg (see aditional info in debian bug)) and later suspend do not > work: It only go to the kde login screen. > > I was unable due to network connectivity to do a full bisect but tested > with the patch I had on my laptop: > > 5.10.101 works, 5.10 from debian works > 5.11 works > 5.12 works > 5.13 suspend works but when resuming the PC is dead I have to reboot > 5.14 seems to work but looking at dmesg it is full of RIP messages at > various places. > 5.15.24 is a described 5.15 from debian is behaving identically > 5.16 from debian is behaving identically. > > >> Is this system S0i3 or regular S3? > > For me it is real S3. > > The proposed patch is intended for INTEl + intel gpu + amdgpu but I have > dual amd GPU. It doesn't really matter what the platform is, it could still potentially help on your system, it depends on the bios implementation for your platform and how it handles suspend. You can try the patch, but I don't think you are hitting the same issue. I bisect would be helpful in your case. Alex
Bug#1005005: same behavior on my MSI Bravo 17 A4DDR : second resume fails and exception in kernel traces
On Wed, Feb 16, 2022 at 2:56 PM Eric Valette wrote: > > On Tue, 15 Feb 2022 15:42:27 -0500 Alex Deucher > wrote: > > What chip is this? Can you provide the full dmesg output? > > Its a a renoir chip with a second gpu : [Radeon RX 5500/5500M / Pro 5500M]. Thanks. Can you attach the dmesg output? Can you bisect? Alex > > > Processor Information > Socket Designation: FP6 > Type: Central Processor > Family: Zen > Manufacturer: Advanced Micro Devices, Inc. > ID: 01 0F 86 00 FF FB 8B 17 > Signature: Family 23, Model 96, Stepping 1 > Flags: > FPU (Floating-point unit on-chip) > VME (Virtual mode extension) > DE (Debugging extension) > PSE (Page size extension) > TSC (Time stamp counter) > MSR (Model specific registers) > PAE (Physical address extension) > MCE (Machine check exception) > CX8 (CMPXCHG8 instruction supported) > APIC (On-chip APIC hardware supported) > SEP (Fast system call) > MTRR (Memory type range registers) > PGE (Page global enable) > MCA (Machine check architecture) > CMOV (Conditional move instruction supported) > PAT (Page attribute table) > PSE-36 (36-bit page size extension) > CLFSH (CLFLUSH instruction supported) > MMX (MMX technology supported) > FXSR (FXSAVE and FXSTOR instructions supported) > SSE (Streaming SIMD extensions) > SSE2 (Streaming SIMD extensions 2) > HTT (Multi-threading) > Version: AMD Ryzen 7 4800H with Radeon Graphics > Voltage: 1.2 V > External Clock: 100 MHz > Max Speed: 4300 MHz > Current Speed: 2900 MHz > Status: Populated, Enabled > Upgrade: None > L1 Cache Handle: 0x000D > L2 Cache Handle: 0x000E > L3 Cache Handle: 0x000F > Serial Number: Unknown > Asset Tag: Unknown > Part Number: Unknown > Core Count: 8 > Core Enabled: 8 > Thread Count: 16 > Characteristics: > 64-bit capable > Multi-Core > Hardware Thread > Execute Protection > Enhanced Virtualization > Power/Performance Control
Bug#1005005: same behavior on my MSI Bravo 17 A4DDR : second resume fails and exception in kernel traces
What chip is this? Can you provide the full dmesg output? Alex On Tue, Feb 15, 2022 at 1:15 PM Eric Valette wrote: > > Since I upgraded from 5.10 (own compiled kernel or debian kernel) to > 5.15 (own compiled from same config or debian kernel) and even 5.16 > kernel from debian, I get this behavior : > > 1) First suspend and resume works, > 2) But later suspendend always fails. I have kernel > exceptions in amdgpu : > > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.803952] Hardware name: > Micro-Star International Co., L > td. Bravo 17 A4DDR/MS-17FK, BIOS E17FKAMS.117 10/29/2020 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.803956] Workqueue: pm > pm_runtime_work > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.803966] RIP: > 0010:dm_suspend+0x241/0x260 [amdgpu] > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804340] Code: 4c 89 e6 4c 89 > ef e8 ee 8a 16 00 83 f8 0 > 1 74 21 89 c2 48 c7 c6 a0 59 69 c1 48 c7 c7 60 83 76 c1 e8 14 ba 06 ff > e9 6d ff ff ff <0f> 0b e9 > f8 fd ff ff 4c 89 e6 4c 89 ef e8 6d ba 15 00 e9 56 ff ff > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804344] RSP: > 0018:ae6040647c90 EFLAGS: 00010286 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804348] RAX: > RBX: 973088a4 RC > X: > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804351] RDX: 000a > RSI: RD > I: 973088a4 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804353] RBP: > R08: 03c0ca00 R0 > 9: 80380002 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804356] R10: 9730860f25a0 > R11: 005f R1 > 2: 973088a4 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804358] R13: 97308132a0d0 > R14: 0008 R1 > 5: > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804361] FS: > () GS:97339f68000 > 0() knlGS: > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804364] CS: 0010 DS: > ES: CR0: 80050 > 033 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804366] CR2: 7fb8c9ce6000 > CR3: 0001115fa000 CR > 4: 00350ee0 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804369] Call Trace: > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804375] > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804380] ? > nv_common_set_clockgating_state+0xa3/0xb0 [ > amdgpu] > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804693] > amdgpu_device_ip_suspend_phase1+0x63/0xc0 [am > dgpu] > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.804977] > amdgpu_device_suspend+0x66/0x110 [amdgpu] > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805260] > amdgpu_pmops_runtime_suspend+0xad/0x180 [amdg > pu] > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805542] > pci_pm_runtime_suspend+0x5a/0x160 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805549] ? pci_dev_put+0x20/0x20 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805553] > __rpm_callback+0x44/0x150 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805558] ? pci_dev_put+0x20/0x20 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805561] rpm_callback+0x59/0x70 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805565] ? pci_dev_put+0x20/0x20 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805568] rpm_suspend+0x14a/0x720 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805572] ? > _raw_spin_unlock+0x16/0x30 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805580] ? > finish_task_switch.isra.0+0xc1/0x2f0 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805586] ? > __switch_to+0x114/0x440 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805593] > pm_runtime_work+0x94/0xa0 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805597] > process_one_work+0x1e8/0x3c0 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805604] worker_thread+0x50/0x3b0 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805608] ? > rescuer_thread+0x370/0x370 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805611] kthread+0x16b/0x190 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805616] ? > set_kthread_struct+0x40/0x40 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805621] ret_from_fork+0x22/0x30 > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805630] > Feb 14 15:40:58 pink-floyd3 kernel: [ 830.805632] ---[ end trace > 8d77579b410d926d ]--- > Feb 14 15:40:58 pink-floyd3 kernel: [ 831.142133] amdgpu :03:00.0: > [drm:amdgpu_ring_test_hel > per [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110) > Feb 14 15:40:58 pink-floyd3 kernel: [ 831.142444] > [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KGQ d > isable failed > Feb 14 15:40:59 pink-floyd3 kernel: [ 831.462157] amdgpu :03:00.0: > [drm:amdgpu_ring_test_hel > per [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110) > Feb 14 15:40:59 pink-floyd3 kernel: [ 831.462465] > [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KCQ d > isable failed > Feb 14 15:40:59 pink-floyd3 kernel: [ 831.782375] > [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* faile > d to halt cp gfx > Feb 14 15:41:05 pink-floyd3 kernel: [ 837.297839] amdgpu :03:00.0: > amdgpu: SMU: I'm not
Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?
On Sat, Feb 12, 2022 at 1:23 PM Salvatore Bonaccorso wrote: > > Hi Alex, hi all > > In Debian we got a regression report from Dominique Dumont, CC'ed in > https://bugs.debian.org/1005005 that afer an update to 5.15.15 based > kernel, his machine noe longer suspends correctly, after screen going > black as usual it comes back. The Debian bug above contians a trace. > > Dominique confirmed that this issue persisted after updating to 5.16.7 > furthermore he bisected the issue and found > > 3c196f0510912645c7c5d9107706003f67c3 is the first bad commit > commit 3c196f0510912645c7c5d9107706003f67c3 > Author: Alex Deucher > Date: Fri Nov 12 11:25:30 2021 -0500 > > drm/amdgpu: always reset the asic in suspend (v2) > > [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ] > > If the platform suspend happens to fail and the power rail > is not turned off, the GPU will be in an unknown state on > resume, so reset the asic so that it will be in a known > good state on resume even if the platform suspend failed. > > v2: handle s0ix > > Acked-by: Luben Tuikov > Acked-by: Evan Quan > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > to be the first bad commit, see https://bugs.debian.org/1005005#34 . > > Does this ring any bell? Any idea on the problem? Does the system actually suspend? Putting the GPU into reset on suspend shouldn't cause any problems since the power rail will presumably be cut by the platform. Is this system S0i3 or regular S3? Does this patch help by any chance? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e55a3aea418269266d84f426b3bd70794d3389c8 Alex > > Regards, > Salvatore
Bug#786816: xserver-xorg-video-radeon: Leaving X (suspend, switch to VT) scrambles the desktop colours
On Wed, May 20, 2015 at 4:53 PM, rw r...@shadowrobot.com wrote: Package: xserver-xorg-video-radeon Version: 1:7.5.0-1 Severity: normal Dear Maintainer, Using X on a Thinkpad T60, just upgraded to Debian 8. Previous versions worked fine for suspend/resume/switch to VT and back Now switching out of the desktop does something I can only describe as change RGB for GBR or similar. Black/white remains perfectly legible, but colours are shifted into a different colour in such a way that the screen is mostly not legible You appear to have disabled kms somehow and you are getting the vesa driver rather than the native radeon driver. Alex [18.639] (II) [KMS] drm report modesetting isn't supported. [18.639] (II) [KMS] drm report modesetting isn't supported. [18.639] (II) [KMS] drm report modesetting isn't supported. [18.645] (WW) Falling back to old probe method for modesetting [18.657] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [18.658] (II) VESA(0): VESA BIOS detected [18.658] (II) VESA(0): VESA VBE Version 3.0 [18.658] (II) VESA(0): VESA VBE Total Mem: 16384 kB [18.658] (II) VESA(0): VESA VBE OEM: ATI ATOMBIOS [18.658] (II) VESA(0): VESA VBE OEM Software Rev: 9.12 [18.658] (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc. [18.658] (II) VESA(0): VESA VBE OEM Product: M56GL [18.658] (II) VESA(0): VESA VBE OEM Product Rev: 01.00 [18.715] (II) VESA(0): Creating default Display subsection in Screen section Default Screen for depth/fbbpp 24/32 [18.715] (==) VESA(0): Depth 24, (--) framebuffer bpp 32 [18.715] (==) VESA(0): RGB weight 888 [18.715] (==) VESA(0): Default visual is TrueColor [18.715] (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) [18.715] (II) Loading sub module ddc [18.716] (II) LoadModule: ddc [18.716] (II) Module ddc already built-in [19.122] (II) VESA(0): VESA VBE DDC supported [19.122] (II) VESA(0): VESA VBE DDC Level 2 [19.122] (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec. [19.371] (II) VESA(0): VESA VBE DDC read successfully [19.372] (II) VESA(0): Manufacturer: LEN Model: 4022 Serial#: 0 [19.372] (II) VESA(0): Year: 2006 Week: 36 [19.372] (II) VESA(0): EDID Version: 1.3 [19.372] (II) VESA(0): Digital Display Input [19.372] (II) VESA(0): Max Image Size [cm]: horiz.: 29 vert.: 21 [19.372] (II) VESA(0): Gamma: 2.20 [19.372] (II) VESA(0): DPMS capabilities: StandBy Suspend Off [19.372] (II) VESA(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 [19.372] (II) VESA(0): First detailed timing is preferred mode [19.372] (II) VESA(0): redX: 0.610 redY: 0.330 greenX: 0.300 greenY: 0.530 [19.372] (II) VESA(0): blueX: 0.150 blueY: 0.130 whiteX: 0.313 whiteY: 0.329 [19.372] (II) VESA(0): Supported established timings: [19.372] (II) VESA(0): 640x480@60Hz [19.372] (II) VESA(0): 800x600@60Hz [19.372] (II) VESA(0): 1024x768@60Hz [19.372] (II) VESA(0): Manufacturer's mask: 0 [19.372] (II) VESA(0): Supported standard timings: [19.372] (II) VESA(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 [19.372] (II) VESA(0): Supported detailed timing: [19.372] (II) VESA(0): clock: 108.0 MHz Image Size: 287 x 215 mm [19.372] (II) VESA(0): h_active: 1400 h_sync: 1448 h_sync_end 1560 h_blank_end 1688 h_border: 0 [19.372] (II) VESA(0): v_active: 1050 v_sync: 1051 v_sync_end 1054 v_blanking: 1066 v_border: 0 [19.372] (II) VESA(0): Supported detailed timing: [19.372] (II) VESA(0): clock: 90.0 MHz Image Size: 287 x 215 mm [19.372] (II) VESA(0): h_active: 1400 h_sync: 1448 h_sync_end 1560 h_blank_end 1688 h_border: 0 [19.372] (II) VESA(0): v_active: 1050 v_sync: 1051 v_sync_end 1054 v_blanking: 1066 v_border: 0 [19.372] (II) VESA(0): Unknown vendor-specific block f [19.372] (II) VESA(0): LTD141EN9B [19.372] (II) VESA(0): EDID (in hex): [19.372] (II) VESA(0): 000030ae2240 [19.372] (II) VESA(0): 24100103801d1578ea6f959c544c8726 [19.372] (II) VESA(0): 21505421080081800101010101010101 [19.372] (II) VESA(0): 010101010101302a7820511a10403070 [19.372] (II) VESA(0): 13001fd7101825237820511a1040 [19.372] (II) VESA(0): 307013001fd71018000f0090 [19.372] (II) VESA(0): 43329043280f01003064905500fe [19.372] (II) VESA(0): 004c5444313431454e39420a2020003e [19.372] (II) VESA(0): EDID vendor LEN, prod id 16418 [19.372] (II) VESA(0): Printing DDC gathered Modelines: [19.372] (II) VESA(0): Modeline 1400x1050x0.0 108.00 1400 1448 1560 1688 1050 1051 1054 1066 -hsync -vsync (64.0 kHz eP) [19.372] (II) VESA(0): Modeline 1400x1050x0.0 89.97 1400 1448 1560 1688 1050 1051 1054 1066 -hsync -vsync (53.3 kHz e) [19.372] (II)
Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver
On Mon, May 18, 2015 at 4:32 AM, Owen Riddy owen.ri...@gmail.com wrote: No worries. It turns out that the problem was the Color Format of my screen. Dunno what that is, but it was configuring poorly and the open source driver seems happier when it is set to RGB rather than YCbCr. Maybe Catalyst is a bit more forgiving or maybe there is some configuration issue here I don't understand. My problem is solved; there may still be a minor bug here in how the auto-configuration of the driver works. The open source driver does not support YCbCr at the moment. Alex Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 18 May 2015 at 17:41, Michel Dänzer mic...@daenzer.net wrote: On 18.05.2015 16:28, Owen Riddy wrote: I have not, but if I reboot the computer to an install of Jessie using fglrx the tinge is not present; and it appeared shortly after updating to Jessie + unstable. I'll try a few things with the cable report back if any of them have an impact, but the fglrx test suggests this problem is 100% fixable in software. I guess I misunderstood the comments about fglrx in your original report. I agree it's probably a software bug then, though it's more likely in the kernel driver than in the Xorg driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver
On Mon, May 18, 2015 at 3:28 AM, Owen Riddy owen.ri...@gmail.com wrote: I have not, but if I reboot the computer to an install of Jessie using fglrx the tinge is not present; and it appeared shortly after updating to Jessie + unstable. I'll try a few things with the cable report back if any of them have an impact, but the fglrx test suggests this problem is 100% fixable in software. Is it only the HDMI display that is problematic? It might be HDMI packet related. Does your display support audio? You can disable HDMI packets by setting radeon.audio=0 on the kernel command line in grub or at runtime using xrandr (e.g., xrandr --output HDMI-0 --set audio off). If that helps, can you try kernel 4.1? Alex Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 18 May 2015 at 12:56, Michel Dänzer mic...@daenzer.net wrote: On 16.05.2015 21:21, Owen Riddy wrote: Package: xserver-xorg-video-ati Version: 1:7.5.0-1+b1 Severity: important Dear Maintainer, I'm using the open source ati graphics with a 3-screen setup. After upgrading to unstable after the release of Jessie everything ran without issue. I booted into a seperate install of Jessie on the same computer that had flgrx installed, and after rebooting into unstable one of the screens (connected by a HDMI cable) has acquired a distinct green tinge that obscures whatever the screen is trying to show. It is a sort of neon green. This image is a graphical corruption bug - I took a screenshot using ksnapshot and on my other two screens the image dispaled withouth the green tinge. The tinge is not present: * In the BIOS * When GRUB is active * Early in the boot process when the kernel is still printing text * On a separate Debian install on the same hardware, using fglrx I tried changing the gamma settings of the screen and poking at the backlight settings but this did not help. Changing the gamma made a very slight difference but the tinge does nto seem to be caused by a rogue gamma setting. At some points during, eg, shutdown my screens go blank - usually this is black but at present the green tinged screen goes straight green. It sounds like there might be a problem with the physical display connection. Have you checked the connector seating at both ends, maybe unplugging and re-plugging them, or even using a different cable? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783705: xserver-xorg-video-radeon: Weird X wakeup problem since Jessie upgrade
On Wed, Apr 29, 2015 at 7:45 AM, Steve McIntyre st...@einval.com wrote: Package: xserver-xorg-video-radeon Version: 1:7.5.0-1 Severity: normal Hi folks, I upgrade my main office desktop to Jessie on Monday, and just about evrrything worked really well - just half a dozen oro so config files needed merging with new upstream etc. Painless! However, I'm now seeing a really odd problem with X on my machine. I've got an AMD graphics card, which Xorg.0.log tells me is a RADEON(0): Chipset: PITCAIRN (ChipID = 0x6810) and a DP+ connection to a lovely 27 NEC monitor. It works just fine when I'm using it, *but* when I leave it overnight and come in the next morning it doesn't want to wake up properly. I'm locking the screen with Xscreensaver and then turning off the monitor as I leave. In the morning, I turn on the screen and I don't get a display at all. I've wiggled the mouse, hit numlock on the keybard (the numlock led illuminates fine), etc., but no display. I've seen this kind of thing happen in the past on some machines, so I switch to VT1 and back to see if that helps. Still no display at all, either on console or under X. I log in remotely and I can see that the Xorg.0.log file has been updated with mode lines for the monitor, suggesting things have just woken up fine. But still no display. Here's the really weird thing: at this point, the monitor has basically locked up. It won't respond to the power/input/menu butttons at all, and is still showing the blue LED that says I have signal rather than switching to the amber no signal warning. Therefore, I can only assume there's a problem here with some weird invalid DP signal being produced. Yesterday, I gave up and rebooted after a few minutes - I had work to do. Today, I started searching for any other reports like this using my laptop. About ten minutes later while I was doing this (approximately, wasn't paying massive attention at this point), my desktop screen suddenly came to life and now it's working OK. I have no idea of where to even start debugging this. Help! If this is a regression, what previous version was working correctly? Does the problem only happen when you physically power off the monitor? Does it come back ok when you let dpms kick in? How about when you physically disconnect the monitor from the computer? Also, what screensavers are you using? There may be a problematic GL screensaver that's causing a GPU lockup. Can you try forcing a single known stable screensaver? Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782610: linux-image-3.16.0-4-amd64, xserver-xorg-video-radeon: Acer Aspire One 725: black screen in X after resume
On Tue, Apr 14, 2015 at 2:58 PM, Simon Richter s...@debian.org wrote: Package: linux-image-3.16.0-4-amd64,xserver-xorg-video-radeon Severity: normal Hi, I've recently installed an Acer Aspire One 725 with Debian jessie, and found that after resuming from sleep, the display remains black (but backlight is on) with X. Text mode consoles work fine with and without console-setup. This system uses an AMD CPU with integrated graphics: model name: AMD C-70 APU with Radeon(tm) HD Graphics 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Device [1002:980a] As I've already passed that machine back to the owner (with sleep mode disabled in systemd config), it is difficult for me to do further testing. When you say sleep, do you mean suspend/resume or dpms? Depending on the hw involved, this patch might help: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66c2b84ba6256bc5399eed45582af9ebb3ba2c15 Alex Simon -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746409: xserver-xorg-video-radeon: No 3D acceleration with radeon driver.
On Tue, Apr 29, 2014 at 2:58 PM, Владимир Титов megau...@yandex.ru wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.4-8 Severity: normal Greetings everyone.I installed Debian Wheezy 7.5 on HDD. OS boot and GNOME 3 loading in fallback mode with error. I installed firmware-linux-nonfree package and reboot. GNOME loading in fallback mode again. ..xsession-errors says: openConnection: connect: Нет такого файла или каталога cannot connect to brltty at :0 gnome-session-is-accelerated: No hardware 3D support. gnome-session-check-accelerated: Helper exited with code 256 gnome-session[3321]: WARNING: Session 'gnome' runnable check failed: Завершено с кодом 1 dmesg|grep radeon command says: [5.404816] [drm] radeon kernel modesetting enabled. [5.406813] radeon :01:00.0: setting latency timer to 64 [5.411254] radeon :01:00.0: VRAM: 512M 0x - 0x1FFF (512M used) [5.411263] radeon :01:00.0: GTT: 512M 0x2000 - 0x3FFF [5.412519] [drm] radeon: 512M of VRAM memory ready [5.412524] [drm] radeon: 512M of GTT memory ready. [5.415360] [drm] radeon: ib pool ready. [5.474763] platform radeon_cp.0: firmware: agent loaded radeon/RV730_pfp.bin into memory [5.614678] platform radeon_cp.0: firmware: agent loaded radeon/RV730_me.bin into memory [5.678174] platform radeon_cp.0: firmware: agent loaded radeon/R700_rlc.bin into memory [5.682544] radeon :01:00.0: WB enabled [5.682639] radeon :01:00.0: irq 43 for MSI/MSI-X [5.682650] radeon :01:00.0: radeon: using MSI. [5.682703] [drm] radeon: irq initialized. [5.906783] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8500)=0xCAFEDEAD) [5.906846] radeon :01:00.0: disabling GPU acceleration [5.923350] radeon :01:00.0: f712dc00 unpin not necessary [5.924982] radeon :01:00.0: f712d800 unpin not necessary [5.925979] [drm] radeon: power management initialized [5.992586] fbcon: radeondrmfb (fb0) is primary device [6.069809] fb0: radeondrmfb frame buffer device [6.073226] [drm] Initialized radeon 2.16.0 20080528 for :01:00.0 on minor 0 So there is no 3D acceleration even with firmware loaded.I tried to install ATI proprietary driver(fglrx-legacy-driver), it work only if I create file /etc/modprobe.d/fglrx-kms.conf and write options fglrx modeset=1. Otherwise X Server isn't loading - only black screen. With working fglrx GNOME also loading in fallback mode. In Windows graphic card work correct. Can you try a newer kernel? 3.2.0 is pretty old. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742307: xserver-xorg-video-radeon: Radeon HD 6570 (Turks) - severe display corruption esp. after boot
On Sat, Mar 22, 2014 at 1:05 AM, Benjamin Moody benjaminmo...@gmail.com wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.4-8 Severity: important Dear Maintainer, I have a Radeon HD 6570 card manufactured by XFX. I'm having multiple problems with this card, some of which are probably kernel-related rather than X-related. I'm using the stable kernel and Xorg, as you can see below, but I've also tried the X server and drivers from testing (xserver-xorg-core 1.15.0-2, xserver-xorg-video-radeon 7.3.0-1+b1), with the same results. - Disabling KMS (radeon.modeset=0) and using the vesa Xorg driver seems to work perfectly. (Obviously no hardware acceleration.) - If I enable KMS but don't start X, the screen is corrupted (a pattern of wrongly colored pixels in each 64-pixel-wide column.) The corruption is annoying, but consistent (it even looks the same from one boot to the next, although I haven't examined it closely.) See http://i.imgur.com/NxwoaUP.jpg for an example - sorry about the poor quality, and it's uglier than the picture makes it look. - The same effect occurs if I use X with the fbdev driver. In this case I can take a screenshot, and the corruption is not visible in the image file; from this I gather that X's internal memory is perfectly fine and the corruption is entirely on the display side. - If I use KMS and the radeon driver: - When I start X for the first time after booting, the screen is complete garbage. It is filled with either (apparently) white noise, or a scrambled version of whatever was on the screen before I rebooted. Usually, the mouse cursor is displayed; I can move the cursor around, and I can use Ctrl-Alt-Backspace to kill the server. However, I can't tell if the server is responding to any input beyond that. Every few seconds, the screen briefly turns black then reappears. The server log shows a number of error messages along the lines of EQ overflowing (see the second copy of Xorg.0.log below.) - After killing the X server, the console appears fine (the previous corruption has disappeared.) - When I start X for the second time, occasionally it works correctly. More often, I see similar results to the above, and have to kill the server again. - When I start X for the *third* time, everything seems to work correctly (including accelerated GL and Xv, although I haven't tested them thoroughly.) So it appears that there is some sort of initialization that ought to be done by the kernel, but is not being done until the X driver is started. Furthermore, there's some additional initialization needed for the X driver itself to work, which for some reason only happens after starting stopping X repeatedly. Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Is this still an issue with a newer kernel? IIRC, this issue was fixed a while ago. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732514: [PATCH] fixes for Radeon KMS on kFreeBSD
On Wed, Dec 18, 2013 at 4:09 PM, Julien Cristau jcris...@debian.org wrote: On Wed, Dec 18, 2013 at 22:05:27 +0100, Robert Millan wrote: Besides, when it comes to KMS drivers, is there a point in auto-loading them just because the hardware is present? AFAICS it makes a lot more sense to load them only when X is started and we know we will need them. Yes. At least on linux it also gives you the fb console. And there's been a number of bug reports where X failed to start because the radeon kernel driver was loaded too late. You also may want to use the driver without X, e.g., wayland, or headless compute. Additionally, if you have the driver loaded you can use advanced power management features and dpms which are not available with vesa or vga mode. Alex Cheers, Julien ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732514: [PATCH] fixes for Radeon KMS on kFreeBSD
On Wed, Dec 18, 2013 at 4:18 PM, Robert Millan r...@debian.org wrote: On 18/12/2013 22:09, Julien Cristau wrote: On Wed, Dec 18, 2013 at 22:05:27 +0100, Robert Millan wrote: Besides, when it comes to KMS drivers, is there a point in auto-loading them just because the hardware is present? AFAICS it makes a lot more sense to load them only when X is started and we know we will need them. Yes. At least on linux it also gives you the fb console. Oh. Well we don't enable that yet (but now that you mention it, maybe we should...). And there's been a number of bug reports where X failed to start because the radeon kernel driver was loaded too late. Where's this race condition? Is it related to the Linux plumbing, or something that could affect us too? It could affect you too. With UMS, the ddx would load the kernel driver, but the kernel driver didn't actually do anything until the ddx explicitly asked it to something. With UMS, the ddx still took care of hw init, the kernel driver basically just managed dma addresses. With KMS, the kernel driver inits and manages the hw so it takes relatively longer to load and the ddx may try and access the kernel driver before it's finished loading leading to fail. Alex -- Robert Millan ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714510: xserver-xorg-video-radeon: Display corrupted after resume on ATI Radeon HD 2400 XT
On Sun, Jun 30, 2013 at 3:59 AM, Tobias Gerdin tobias.ger...@gmail.com wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.4-8 Severity: important Tags: upstream Dear Maintainer, After resuming system after a suspend (to RAM) the display is corrupted. It is still possible to see what's going on but everything turns into a highly unhealthy-looking (for the display) green-orange flickering mess. The system is this Apple iMac, see: http://www.everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.0-20-inch-aluminum-specs.html I have never gotten this to work in Linux I think, and it's the only issue that keeps me from switching to Linux from OS X (sounds works now as of the Wheezy release). I observe the same issue on Ubuntu (tried 12.04LTS and 13.04). You might try a newer kernel or if you are using EFI to boot, try using the legacy bios option. Unfortunately, macs do just about everything differently you may need some sort of mac specific quirk to make it work properly, especially with EFI boot. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529178: xserver-xorg-video-ati: Suffering from this bug + Possible mitigation
On Tue, Apr 2, 2013 at 10:04 AM, Pablo Oliveira pa...@sifflez.org wrote: Package: xserver-xorg-video-ati Version: 1:6.14.4-8 Followup-For: Bug #529178 Dear Maintainer, After updating my system to wheezy, and in particular the xserver-xorg-video-ati package to version 1:6.14.4-8, I now suffer from a similar issue. I have two monitors. The right one, and only the right one, randomly turns off and on. * I use the default Xorg configuration and setup dual monitors using xrandr --output DVI-0 --left-of DVI-1 --auto. * The two monitors are identical models: SAMSUNG SyncMasterB1940. The problem does not seem to be in the monitors: when I swap the two DVI connectors, the left one starts to flicker on and off and the right one works flawlessly. * If I run xset dpms force off the problems disappears completely. To clarify, do you mean that after a dpms cycle both monitors work correctly? Does a newer kernel help? 3.2 is pretty old. There were a number of display related fixes that went into 3.7 for example. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529178: xserver-xorg-video-ati: Suffering from this bug + Possible mitigation
On Wed, Apr 3, 2013 at 2:22 PM, Pablo Oliveira pa...@sifflez.org wrote: On Wed, Apr 3, 2013 at 3:34 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Apr 2, 2013 at 10:04 AM, Pablo Oliveira pa...@sifflez.org wrote: Package: xserver-xorg-video-ati Version: 1:6.14.4-8 Followup-For: Bug #529178 [...] * If I run xset dpms force off the problems disappears completely. To clarify, do you mean that after a dpms cycle both monitors work correctly? Yes, after turning off DPMS, both monitors work correctly. I have been using the system all day without any flickering problems. Does a newer kernel help? 3.2 is pretty old. There were a number of display related fixes that went into 3.7 for example. I will try with a new kernel and report back. Also, I would add that, like the other people affected by this bug, the problem triggers often when scrolling a window. Is this the same issue? I.e., does the blinking come back after a dpms cycle if you scroll? If so, it sounds like it may be a bandwidth issue. You might try booting with radeon.disp_priority=2 on the kernel command line in grub. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698503: tearing with Radeon HD 6970
On Sat, Jan 19, 2013 at 8:59 AM, Marc Dequènes d...@duckcorp.org wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.4-6 Severity: normal Coin, At the end of the 2012 year, i upgraded my desktop machine, switching from Radeon HD 4890 to Radeon HD 6970. Since then i experience tearing, easily visible when watching videos for example. I was using Unagi at the time, so i stopped using it which only reduced the effect. It is not easy to show the resulting effect so i tried some camera shots (see attached) using the following video : http://www.youtube.com/watch?v=ceX18O9pvLs Unfortunately, it does not seem to show anything proving I'm not drunk. The other machine i can test on has got a Mobility Radeon X300 and besides some slowness display it properly ; shots on this machine also show brightness blocks, even if less blocks and with a perfect separation line. Tell me if i can test anything else. What are you using to render the videos (Xv, GL)? Did you also change your desktop environment? Note that if you are using a compositing manager (compiz, gnome shell, kwm, etc.), the compositing manager is responsible for preventing tearing by syncing screen updates to vsync. If you are using Xv, the driver's anti-tearing Xv features only work when rendering directly to the display buffer. If you are using a composting manager, the driver renders to an offscreen buffer and the compositor is responsible for updating the display buffer with the new Xv data. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations
On Wed, Oct 24, 2012 at 5:41 AM, James Robertson j...@mesrobertson.com wrote: The only other option I was going to try was using a Display port to DVI adapter from the side of my laptop to replace the VGA from the docking station. If I purchase one to try that I'll let you know. I bought a an Active display port adapter for my laptop. That won't even work with resolutions above 1280x1024 under Debian (works fine up to native 1980x1080 res on Windows 7). I wanted to use one of my monitors in portrait mode but the the rotation would not work if I had Option NoAccel true. Of course disabling it meant I get the hideous screen corruption. All of this works fine on Windows 7 with DVI/VGA or Display Port so at least I can confirm it's not a hardware limitation. I am quite bummed to have this problem. Can anyone suggest ways in which I can troubleshoot/resolve it? Can you try a newer kernel? 3.6 or 3.7? That may help with the modesettings. As for the acceleration, corruption, you might try a newer version of mesa. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688828: xserver-xorg-video-radeon: brightness controls don't work
On Tue, Sep 25, 2012 at 8:57 PM, Geoff Crompton geo...@trinity.unimelb.edu.au wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.4-5 Severity: normal Dear Maintainer, The brightness controls on my iMac aren't effective at changing the brightness of either of my displays. They do popup the gnome brightness indicator, and alter the values of /sys/class/backlight/acpi_video0/brightness. But they don't effect the brightness of either the primary display, or the secondary display I've got attached (via a thunderbolt to DVI connector). Likewise the gnome system settings brightness controls slide around, and do alter /sys/class/backlight/acpi_video0/brightness, but don't change the brightness. Rebooting into Mac and setting the brightness there seems to maintain that brightness setting when I reboot back into Linux. I'm booting with grub-efi. If apple uses the built in GPU backlight controller, it may work with the new backlight control patches in my drm-3.7 branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687461: xserver-xorg-video-radeon: HD 6310 video gives only colored snow/black screen
On Wed, Sep 12, 2012 at 5:50 PM, Michael Evans mnev...@geol.umd.edu wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.4-5 Severity: normal Dear Maintainer, I get no video, only colored snow. Boot seems OK up until X is started. The system is then unusable. (I am writing from a different wheezy install). Make sure you install the firmware package and that the firmware is available in the initrd if you are using one. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686971: [radeon] display unwantingly dimmed, dimming state leaking across VT switch
On Fri, Sep 7, 2012 at 3:45 PM, Yann Dirson ydir...@free.fr wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.4-5 Severity: normal What I can easily reproduce: Running xscreensaver-command -activate, and hitting Ctrl-Alt-F1 while it is fading away leaves me on a dimmed tty1. Switching to other text consoles does not change the dimming. Switching back to my X session shows correct luminosity, and it I then go back to text consoles they are OK as well. Not so important if it were not for the original problem, which is not so easy to reproduce: (I was told) there was a Ctrl-alt-Fn console switch while xscreensaver was fading out my X display. When I went back and switched back to my own session, my display was dimmed, while other X displays were not when I switched to them. When I switched to a text console, it was dimmed when I switched from my dimmed X, and was not dimmed when I switched from the other, non-dimmed, ones. A quick look at utils/fade.c in the xscrensaver source shows it is possibly using xf86vidmode for the fading operation, so I went looking for a tool to query the xf86vm settings, but found none. The closest I found was xcalib, but I could not have anything queried with it either. Eventually I guessed right with xcalib -a -c and everything was back in good shape, but less stubborn ones would have rebooted their machines like a windows box long before... The leaking dim state makes me guess the problem would be more in the radeon side of things, rather than at the xf86vm level, but that's a wild guess only... The fade effect is done by adjusting the gamma. When you switch VTs, just the display base address is changed. The gamma is not changed. I suspect this may affect other drivers as well so probably needs to be fixed in common code. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations
On Fri, Jul 20, 2012 at 1:45 PM, Michel Dänzer daen...@debian.org wrote: On Don, 2012-07-19 at 23:43 +1000, James Robertson wrote: Package: xserver-xorg-video-ati Version: 1:6.14.4-5 Severity: normal Dear Maintainer, I have a Lenovo R500 laptop with an [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] graphics chip I recently obtained 2x AOC monitors with a 1920x1080 resolution and have these connected via DVI and VGA to a laptop docking station. The laptop only supports a maximum of 2 displays at once. With the laptop display disabled I get screen tearing and corruption when using 1 or both of the external monitors with 1920x1080 resolution. But strangely if I set one of them to a lower resolution such as 1680x1050 (the other still at 1920x1080) the screen tearing issue dissapears. Odd given a single display gets the tearing... If using the laptop's display in conjunction with either DVI or VGA connected monitor at 1920x1080 I experience no tearing. Also note that rendering can only be synchronized to one head at a time to avoid tearing. If you have windows that span multiple heads, you may get tearing on the non-synced heads. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661943: xserver-xorg-video-radeon: Unable to set native resolution with KMS enabled
On Mon, Mar 5, 2012 at 12:42 PM, Christopher Dow christopher@allstardirectories.com wrote: Unfortunately, my problem is that I can't change the display modes to the native resolution. Even with one display disabled, I still can't set the native resolution. I get the same input timing not supported message every time I have tried. It wouldn't be a problem if the default was not what I wanted but I could change to the correct resolution. Most of my attempts to change the resolution have been been using the KDE display tool (which, as I understand, uses xrandr underneath). However, I've also attempted to use xrandr directly. What mode gets picked when you start up with a single display attached? Can you attach your xorg log with a single display? Does the console pick the correct mode before X starts? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661943: xserver-xorg-video-radeon: Unable to set native resolution with KMS enabled
On Fri, Mar 2, 2012 at 3:30 PM, Christopher Dow
christopher@allstardirectories.com wrote:
Package: xserver-xorg-video-radeon
Version: 1:6.14.3-2
Severity: important
I am unable to set the the native resolution of my monitors with KMS enabled.
Whenever I try to set the native resolution, the monitor displays the
following message message (with resolution replaced with the apropriate
native resolution:
The current input timing is not supported by the monitor display. Please
change your input timing to resolution or any other monitor listed timing
as per the monitor specifications.
I have two monitors ('Dell P2210' and a 'Dell P2010H'). I am not able to the
native resolution for either of these monitors. You can find the
specifications for these monitors here:
http://support.dell.com/support/edocs/monitors/P2210/en/ug/about.htm#Specifications
http://support.dell.com/support/edocs/monitors/P2010H/en/ug/about.htm#Specifications
Whenever boot into Debian, I get this same message for a few seconds and then
the display goes to a lower resolution. I also get the same message if I try
to switch to any of the virtual terminals.
If I disable KMS, I am able to set the native resolution for both of these
monitors (however, then I can't set my desktop to span 2 monitors but that is
probably a different issue).
[13.127] (II) RADEON(0): Output DisplayPort-0 connected
[13.127] (II) RADEON(0): Output DisplayPort-1 connected
[13.127] (II) RADEON(0): Using fuzzy aspect match for initial modes
[13.127] (II) RADEON(0): Output DisplayPort-0 using initial mode 1152x864
[13.127] (II) RADEON(0): Output DisplayPort-1 using initial mode 1152x864
The xserver (not the driver) is picking 1152x864 since it's the
largest common mode supported by both monitors. You'll have to use
xrandr to choose a different mode (or specify different default modes
in your xorg.conf). Alternatively, you can start up X with one
monitor attached and then enable the second one manually with xrandr.
Alex
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658636: Acknowledgement (xserver-xorg-video-radeon: Multiple DRI regressions)
On Tue, Feb 7, 2012 at 7:32 PM, Witold Baryluk bary...@smp.if.uj.edu.pl wrote: So why there are two incompatible drivers, especially when radeon looks to be providing framebuffer anyway? Is radeonfb module supporting even some older hardware so it is keeped in kernel? radeon covers all hw radeonfb covers and more. The reason radeonfb is still around is that it covers a few corner cases (suspend and resume on ppc mac cards) which hasn't been ported over to radeon yet. On x86, there is no reason to use radeonfb. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630345: gdb trace and logs with experimental drivers
On Sun, Jan 8, 2012 at 2:15 AM, Craig Small csm...@debian.org wrote: On Wed, Jan 04, 2012 at 09:48:50AM -0500, Alex Deucher wrote: Is there any chance you are using a hybrid laptop with both Intel and AMD GPUs in it? Based on your log this looks like it a MUX-less one It is definitely a hybrid laptop with Intel and AMD GPUs. I'm not sure if it is muxless or not. This has worked with the closed-source fglrx drivers. They support this setup. MUX-less systems aren't supported yet as we need a fair amount of drm and X infrastructure to handle buffer sharing between GPUs and decoupled display and rendering. When you mean we you're talking about xorg and the people supporting it? I completely understand this is really a problem of ATI's doing. It's a problem of a lack of manpower in the open source stack. It's a huge amount of non-driver work to support this. Alex - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630345: gdb trace and logs with experimental drivers
On Wed, Jan 4, 2012 at 4:54 AM, Craig Small csm...@debian.org wrote: I tried the radeon and intel drivers. The intel bit works ok but when i make a minimal xorg.conf to use the radeon chip the X server crashes. Attached is the gdb logs and Xorg.0.log files. I hope these help make sense of what is going wrong. Is there any chance you are using a hybrid laptop with both Intel and AMD GPUs in it? Based on your log this looks like it a MUX-less one in which case the discrete AMD card is not actually connected to any displays (or if it is, it might only be connected to an external monitor port). We can double check by posting your dmesg output. MUX-less systems aren't supported yet as we need a fair amount of drm and X infrastructure to handle buffer sharing between GPUs and decoupled display and rendering. Alex - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649448: udev loading radeon drivers garbles screen output
On Tue, Nov 22, 2011 at 7:08 AM, Touko Korpela touko.korp...@iki.fi wrote: On Mon, Nov 21, 2011 at 09:33:28AM -0500, Alex Deucher wrote: On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote: reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3 severity 649448 important retitle 649448 radeon (evergreen): random-looking pattern of pixels when firmware not installed tags 649448 + upstream quit Hi Martin, Martin von Gagern wrote: Version: 3.0.0-3 [...] Just installed a wheezy setup using debootstrap, adding grub-pc and linux-image-amd64 after the chroot was created. The kernel boots, the initrd seems all right. When the main system boots up, udev gets launced pretty early. Soon after it is started, the screen turns into a pretty random-looking pattern of pixels, making the console pretty unusable. This also happens in recovery i.e. single-user mode. [...] Possible workarounds seem to include: [...] - Adding a line blacklist radeon to /etc/modprobe.d/blacklist.conf, followed by running depmod -a. [...] [ 150.125768] r600_cp: Failed to load firmware radeon/SUMO2_pfp.bin [ 150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 150.125859] radeon :00:01.0: disabling GPU acceleration Yes, the radeon driver currently copes poorly when firmware is missing. Compare [1], [2], [3]. [...] Not having GPU accelleration due to lack of free firmware is acceptable. Not having a usable text console can be a real problem. Agreed. The radeon driver should be bailing out when firmware is missing for cards that need it, but that is not working for some reason. [...] At the time I converted the radeon driver to load external firmware, it was apparently only required for 3D acceleration and both KMS and 2D acceleration of X worked without it, at least on those systems I tested (which were quite old, R100-R300 families). Therefore failure to load firmware would only result in DRM (3D acceleration support) being disabled. However, it looks like driver support for the R600 family onward now absolutely requires the 'RLC' firmware blobs: commit d8f60cfc93452d0554f6a701aa8e3236cbee4636 Author: Alex Deucher alexdeuc...@gmail.com Date: Tue Dec 1 13:43:46 2009 -0500 drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3) And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the 'MC' firmware blobs: commit 0af62b0168043896a042b005ff88caa77dd94d04 Author: Alex Deucher alexdeuc...@gmail.com Date: Thu Jan 6 21:19:31 2011 -0500 drm/radeon/kms: add ucode loader for NI Therefore I think that at least r600_init(), rv770_init(), evergreen_init() and cayman_init() should be treating failure to load firmware as a fatal error. R6xx, r7xx should work ok without the RLC ucode, you just won't get acceleration. With chips that require the MC ucode, the driver will bail if the MC ucode is not available. In what kernel versions should that be true? These bugs are reported that question it (some are reported against older kernels). http://bugs.debian.org/607194 http://bugs.debian.org/637943 http://bugs.debian.org/627497 and also my report: http://bugs.debian.org/646306 Should work and well tested are different things. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649448: udev loading radeon drivers garbles screen output
On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote: reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3 severity 649448 important retitle 649448 radeon (evergreen): random-looking pattern of pixels when firmware not installed tags 649448 + upstream quit Hi Martin, Martin von Gagern wrote: Version: 3.0.0-3 [...] Just installed a wheezy setup using debootstrap, adding grub-pc and linux-image-amd64 after the chroot was created. The kernel boots, the initrd seems all right. When the main system boots up, udev gets launced pretty early. Soon after it is started, the screen turns into a pretty random-looking pattern of pixels, making the console pretty unusable. This also happens in recovery i.e. single-user mode. [...] Possible workarounds seem to include: [...] - Adding a line blacklist radeon to /etc/modprobe.d/blacklist.conf, followed by running depmod -a. [...] [ 150.125768] r600_cp: Failed to load firmware radeon/SUMO2_pfp.bin [ 150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 150.125859] radeon :00:01.0: disabling GPU acceleration Yes, the radeon driver currently copes poorly when firmware is missing. Compare [1], [2], [3]. [...] Not having GPU accelleration due to lack of free firmware is acceptable. Not having a usable text console can be a real problem. Agreed. The radeon driver should be bailing out when firmware is missing for cards that need it, but that is not working for some reason. [...] At the time I converted the radeon driver to load external firmware, it was apparently only required for 3D acceleration and both KMS and 2D acceleration of X worked without it, at least on those systems I tested (which were quite old, R100-R300 families). Therefore failure to load firmware would only result in DRM (3D acceleration support) being disabled. However, it looks like driver support for the R600 family onward now absolutely requires the 'RLC' firmware blobs: commit d8f60cfc93452d0554f6a701aa8e3236cbee4636 Author: Alex Deucher alexdeuc...@gmail.com Date: Tue Dec 1 13:43:46 2009 -0500 drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3) And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the 'MC' firmware blobs: commit 0af62b0168043896a042b005ff88caa77dd94d04 Author: Alex Deucher alexdeuc...@gmail.com Date: Thu Jan 6 21:19:31 2011 -0500 drm/radeon/kms: add ucode loader for NI Therefore I think that at least r600_init(), rv770_init(), evergreen_init() and cayman_init() should be treating failure to load firmware as a fatal error. R6xx, r7xx should work ok without the RLC ucode, you just won't get acceleration. With chips that require the MC ucode, the driver will bail if the MC ucode is not available. Alex Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648598: Gnome3: complete system freeze, fallback OK
On Sun, Nov 13, 2011 at 5:26 AM, Joost Kraaijeveld j.kraaijev...@askesis.nl wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.3-1 Severity: critical Justification: breaks the whole system Dear Maintainer, After some time running Gnome3 with the new shell my system lock up. It completely freezes, nothing works: no alt+F1 , ctrl+alt+del, alt-backspace, no remote login via ssh possible and the machine does not respons to pings. The only way to reboot is using the power button (off and than on). Just using the reset button results in not finding the boot disk anymore. I can't find anything in any of the log files (messages, kernel, debug, daemon). The freeze *almost* always happens during drag and drop operations or when using the mouse to click on icons (menu, evolution expanding threads etc). Sometimes it happens when doing nothing with the system but when audio is playing. Running Gnome3 in the fallback mode works OK and no freeze happens. I would suggest using KMS rather than UMS. When you switch to KMS, I'd also suggest using the r600 gallium 3D driver and removing the Virtual line from your xorg.conf. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648598: Gnome3: complete system freeze, fallback OK
On Mon, Nov 14, 2011 at 9:34 AM, Joost Kraaijeveld j.kraaijev...@askesis.nl wrote: On Mon, 2011-11-14 at 09:15 -0500, Alex Deucher wrote: I would suggest using KMS rather than UMS. When you switch to KMS, I'd also suggest using the r600 gallium 3D driver and removing the Virtual line from your xorg.conf. Ah, there is an error in the KMS radeon-kms.conf file: when it crashed the (now commented out) options radeon modeset=1 was active. I had to disable that to be able to use the machine and file the bug. Sorry about the confusion. Further, is there a difference between the xserver-xorg-video-radion driver and the r600 gallium driver and if so, what is the Debian package for that? I did notice that glxinfo did say it was using gallium 0.4. Would that mean that I was using the right driver? I'm not familiar with the debian packages. The r600 gallium driver is the 3D OpenGL driver. xorg-video-radeon is the Xorg ddx(2D, Xv, xrandr, etc.). If glxinfo says gallium 0.4 on RV670 that is correct. Alex -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648222: Significant 2D performance regression with ColorTiling
On Sun, Nov 13, 2011 at 1:34 PM, Iustin Pop ius...@debian.org wrote: On Thu, Nov 10, 2011 at 06:15:43PM +0100, Michel Dänzer wrote: On Don, 2011-11-10 at 18:01 +0100, Michal Suchanek wrote: On 10 November 2011 17:46, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop ius...@debian.org wrote: The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a significant performance degradation in 2D (yes, I understand it should make 3D faster, but I didn't know it should slow down 2D applications). I'm using plain 2D environment (openbox, no compositing, anything) and plain xterm (bitmap fonts, no AA, etc.). The speed of display text has changed significantly enough that I can see my mutt refreshing the inbox and drawing the lines. Tiling will speed up all rendering (2D and 3D). However, it sounds like you are using an environment that is mostly software rendering. As such in order for the CPU to access tiled buffers, the GPU has to copy them to a linear buffer before CPU can access it properly. FWIW I have color tiling enabled and have no speed issues in urxvt - TrueType fonts, AA enabled, etc. Unlike xterm urxvt (rxvt-unicode) uses some special font-rendering libraries, however. If I understand it correctly xterm would use the in-server bitmap font rendering which the X server can accelerate as much as it wants. Core bitmap fonts are completely unaccelerated so far with EXA. xterm can also use Xft for font rendering via the -fa option though, which is well accelerated. Hi all, thanks for the replies. I've tested further and this seems to be a problem specific to xterm (and possibly other software? not sure how to test e.g. firefox's UI speed): Test file: ~20K lines. I've chosen the font sizes so as to have the same number of lines in full-screen. The timing is simply time cat file. ColorTiling disabled: xterm -fn fixed: ~3.3s xterm -fa Mono -fs 8: ~8.6s rxvt-unicode -fn fixed: ~0.07s rxvt-unicode -fn xft:Mono:pixelsize=11: ~0.05s ColorTiling enabled: xterm -fn fixed: ~21s xterm -fa Mono -fs 8: ~7.8s rxvt-unicode -fn fixed: ~0.6s usually, sometimes ~0.1s?? rxvt-unicode -fn xft:Mono:pixelsize=11: ~0.05s So it seems to me that: a) whatever xterm does, it is very sub-optimal b) while xterm's -fa mode is indeed sped up by ColorTiling, it's still many times slower than with ColorTiling disabled and using core fonts c) also rxvt-unicode with core fonts is slowed down by color tiling, sometimes very much so (10x) Based on this I think this is mostly an xterm bug (-fa should/could be much faster), but I wonder if it also applies to other purely software 2D rendering. It likely does. We optimize the accelerated paths rather than the slow paths. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648222: Significant 2D performance regression with ColorTiling
On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop ius...@debian.org wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.3-1 Severity: minor Hi, The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a significant performance degradation in 2D (yes, I understand it should make 3D faster, but I didn't know it should slow down 2D applications). I'm using plain 2D environment (openbox, no compositing, anything) and plain xterm (bitmap fonts, no AA, etc.). The speed of display text has changed significantly enough that I can see my mutt refreshing the inbox and drawing the lines. Cat-ing a big (~4K lines of text) file on a full-screen xterm is: - 6.14.2-2 (low power profile): ~0.8s - 6.14.3 (high power) : ~3.1s - 6.14.3 (low power) : ~5.0s So it's more than 5x time slower, which makes it unpleasant. Simply disabling ColorTiling makes the problem go away, and 6.14.3 is as fast as 6.14.2. Tiling will speed up all rendering (2D and 3D). However, it sounds like you are using an environment that is mostly software rendering. As such in order for the CPU to access tiled buffers, the GPU has to copy them to a linear buffer before CPU can access it properly. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630345: xserver-xorg-video-radeon: Xserver crashes with HD6700M card
On Mon, Aug 22, 2011 at 1:38 PM, Willian Gustavo Veiga wilt...@gmail.com wrote: Of course I can Alex. It's attached. Thank you very much. The radeon has no connectors specified in the vbios so it's muxless. Not much we can do with it until X gets re-architected to decouple display and rendering. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630345: xserver-xorg-video-radeon: Xserver crashes with HD6700M card
On Sun, Aug 21, 2011 at 1:13 PM, Willian Veiga wilt...@gmail.com wrote: Alex Deucher, I have an AMD Radeon HD 6470M but I can't select which card I want to use in the BIOS setup. How do I know if my GPU display is MUXes or MUX-less? I've tried to select the discrete card using vgaswitcheroo but i get a black screen and the computer crashes. Most new systems are muxless, so it's probably muxless. Can you post the dmesg from your system? Alex # lspci -v 01:00.0 VGA compatible controller: ATI Technologies Inc NI Seymour00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 04ca Flags: bus master, fast devsel, latency 0, IRQ 54 Memory at f640 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 [AMD Radeon HD 6470M] (prog-if 00 [VGA controller]) Subsystem: Dell Device 04ca Flags: bus master, fast devsel, latency 0, IRQ 56 Memory at e000 (64-bit, prefetchable) [size=256M] Memory at f7b2 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at f7b0 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 ? Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon # uname -a Linux willian 3.0.0-1-amd64 #1 SMP Wed Aug 17 04:08:52 UTC 2011 x86_64 GNU/Linux Thank you very much. ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630345: xserver-xorg-video-radeon: Xserver crashes with HD6700M card
On Mon, Jun 13, 2011 at 2:50 AM, Craig Small csm...@debian.org wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.2-1 Severity: important I have one of these dual card laptops. It works fine with the simple Intel driver. I made a small xorg.conf file and rebooted. This file only specified the radeon driver and the BusID. When I did that the server crashed every time. Is there an option in your bios setup to select the discrete graphics? Try selecting that. vgaswitcheroo only supports hybrid GPUs with display MUXes. Some new laptops are MUX-less whihc means the display hardware is only attached to one of the GPUs and the other one is strictly used for rendering. Unfortunately, the X server needs a lot of work to support that scenario so it will not be supported any time soon in the open source drivers. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627554: xserver-xorg-video-radeon: HD 5750 3rd screen displays interesting psychedelic colour swirl pattern covering whole screen
On Tue, May 24, 2011 at 4:00 PM, Tim Wootton t...@tee-jay.demon.co.uk wrote: On 22/05/11 21:49, Tim Wootton wrote: On 22/05/11 21:16, Alex Deucher wrote: Are you using native DP or a DP to HDMI converter? If you are using a converter, is it an active or passive converter? If it's passive, you'll have the same limitation as before. It's a passive, got an active on order now, so I will see if that does the trick. Thanks for the advice. Ok,so now using an active converter (Sapphire with Eyefinity logo), but still the same problem, perhaps it could be a bug after all. Please attach your xorg log and dmesg output. You might also want to try the recent DP patches I posted for 2.6.40. They are available in the radeon-drm-testing branch of Dave's tree: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627554: xserver-xorg-video-radeon: HD 5750 3rd screen displays interesting psychedelic colour swirl pattern covering whole screen
On Sun, May 22, 2011 at 3:37 PM, Tim Wootton t...@tee-jay.demon.co.uk wrote: On 22/05/11 00:06, Alex Deucher wrote: Not a bug. Only 2 non-DP monitors are supported since there are only two plls. If you want 3 or more monitors the rest have to be DP. The fact that you can make it work with some fiddling is pure luck and is completely unsupported. You end up with one of the plls driving two monitors which only works if both monitors have the same clock and you get the ordering right. Switched HDMI for DP, so now running 2 x DVI and 1 x DP, I get exactly the same symptoms. Are you using native DP or a DP to HDMI converter? If you are using a converter, is it an active or passive converter? If it's passive, you'll have the same limitation as before. Alex Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627554: xserver-xorg-video-radeon: HD 5750 3rd screen displays interesting psychedelic colour swirl pattern covering whole screen
On Sat, May 21, 2011 at 6:11 PM, Tim Wootton t...@tee-jay.demon.co.uk wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.1-1+b1 Severity: normal Tags: upstream When trying to get 3 screens working off an HD 5750, one of the screens is coming up with cyan-ish background part way through boot, and when x launches I get an interesting psychedelic colour swirl across that whole screen. It's just possible to make out shapes of icons, windows etc. that should be displayed on the screen. In troubleshooting I have discovered that if I install the closed source driver reboot, and then uninstall it and reboot again back into the open driver then the 3 monitor setup works fine with the open driver. I think the closed driver must be setting somthing up during boot that allows the open driver to work with the 3rd screen so long as I havn't removed power completely only booted with a reset. I can tell early in the boot which screen is going to have the problem by the cyan background. I have the monitors connected to the 2xDVI and 1xHDMI, the DP is unused. Not a bug. Only 2 non-DP monitors are supported since there are only two plls. If you want 3 or more monitors the rest have to be DP. The fact that you can make it work with some fiddling is pure luck and is completely unsupported. You end up with one of the plls driving two monitors which only works if both monitors have the same clock and you get the ordering right. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626115: xserver-xorg-video-radeon: kernel crash after period of user inactivity
On Sun, May 8, 2011 at 7:13 PM, jamie j...@mayfirst.org wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.1-1 Severity: normal While actively working on my laptop, I experience no problems. However, when I am away from the machine for more than about 5 or 10 minutes, the screen either goes blank (still backlit, but unresponsive to keyboard presses) or I get a kernel dump. Below is a hand-typed representation of what I hope is the relevent information from the last kernel dump (subject to typos). Note - I tried and failed to manually trigger the problem by triggering my xscreensaver and by executing: set dpms standby|suspend|off|on etc. This problem began after upgrading to xserver-xorg-video-radeon 1:6.14.1-1 Thanks for all your work! jamie invalid opcode: Pid: 5107, comm: kworker/0:0 Tainted: G C 2.6.38-2-amd64 #1 TOSHIBA Satellite T115D/Satellite T115D Call Trace: kref_sub ttm_bo_reserve [ttm] radeon_unpin_work_func [radeon] T.765 [radeon] radeon_unpin_work_func [radeon] process_one_work worker_thread worker_thread worker_thread kthread kernel_thread_helper kthread kernel_thread_helper Code: .. RIP ttm_bo_ref_bug [ttm] RSP Looks like: https://bugzilla.kernel.org/show_bug.cgi?id=32402 You can disable pageflipping as a workaround. Option EnablePageFlip False -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622993: every 10s I get [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ...
2011/5/1 Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com: On Dom 01 May 2011 18:09:27 Thibaut Girka escribió: [snip] I'm not talking about ignoring broken EDIDs, but about actually fixing them[1]. This is clearly not my problem. I have two monitors, both the same brand and model. One is connected to the VGA output and the other one on the DVI. No matter wich one I plug into the DVI port, it detetcts the EDID worngly, while the VGA does it correctly. Or the VGA port is ignoring broken edids even without the forget broken edids patch, or somehow the DVI port is getting wrong edids, or checksumming them wrongly. You might try the patch here: https://bugs.freedesktop.org/show_bug.cgi?id=27708#c7 If you are using a DVI or HDMI port, some TV's don't properly update their checksums for different ports if they have minor edid changes for the port. Also, some hdmi receivers/switches mangle the edids. Alex Kinds regards, Lisandro. -- One of the biggest wake-up calls of my career was when I saw a record contract. I said, 'Wait - you sell it for $18.98 and I make 80 cents? And I have to pay you back the money you lent me to make it and then you own it? Who the f**k made that rule? Oh! The record labels made it because artists are dumb and they'll sign anything' - like I did. Trent Reznor, Nine Inch Nails on http://contactmusic.com/ http://tinyurl.com/c2wda4 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622993: every 10s I get [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ...
2011/5/2 Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com: On Lun 02 May 2011 11:23:48 Alex Deucher escribió: [snip] You might try the patch here: https://bugs.freedesktop.org/show_bug.cgi?id=27708#c7 If you are using a DVI or HDMI port, some TV's don't properly update their checksums for different ports if they have minor edid changes for the port. Also, some hdmi receivers/switches mangle the edids. Thanks, that's exactly the patch I'm already using. Works perfectly :-) I should mention that both monitors are VGA, so I'm using a VGA←→DVI adpator. And as I said before, it used to work without the patch :-) Can you bisect? I suspect the culprit is one of the patches that made the kernel edid parser more strict. Alternatively, you may have been using ums previously which does not have the same strict checks as the kernel. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585777: Radeon gamma bug, display too bright when using VGA output
On Tue, Apr 26, 2011 at 3:56 AM, Andrew Rule a.r...@freeuk.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I also have this problem. It appeared for me when I upgraded from Xorg 1.7.x to Xorg 1.9.5 I am using ATI Radeon Mobility 9200 (M9+) 5C63 (AGP) (ChipID = 0x5c63) as X reports it, and Linux amos 2.6.38.3 #2 SMP PREEMPT Sat Apr 16 22:03:19 BST 2011 i686 GNU/Linux from kernel.org I tried setting Gamma in /etc/X11/xorg.conf, but it didn't pick it up. If I run xgamma after logging in to X, it *does* change the gamma - but still not enough. So I can set Gamma to 0.3 in the file, but if I set it using xgamma, it actually darkens the screen somewhat - but it is still not right. Output from xgamma: - - Red 0.300, Green 0.300, Blue 0.300 - Red 0.300, Green 0.300, Blue 0.300 It's not the gamma, but the dac adj values. I tried radeontool regset DAC_MACRO_CNTL 0x0808 but it didn't work for me. (Perhaps that is not a surprise, I am using a tower PC, not a laptop.) You are probably using the secondary dac. The dac adjust values for the TV dac are in TV_DAC_CNTL. Perhaps I should not mention this here, but X is also unstable for me under KDE now, so I'm using sawfish for the time being. Specifically, it crashes when notifications popup in KDE. Another problem I have noticed is that when scrolling a window under another window, the contents of the lower window smudges. O, and popup hints from firefox come up in the wrong place for the search box. And, as you can see from the attached files, I am not using KMS - because I found that unstable since upgrading the kernel from 2.6.36.1 to 2.6.38.x (although previously the virtual terminals had not worked at all, and now they do occasionally; but it was stable under X, now it is not.) What is unstable with KMS? KMS is more likely to be fixed that UMS at this point. If you want to fix UMS, you'll probably have to bisect xf86-video-ati to find out what change caused the breakage. Your time would be better off spend bisecting to see what caused the instability with KMS. Alex Please ask further questions if you need. I'm gonna try downgradeing X, cos I'd like to have a screen I can look at pictures on :-) Sincerely, Andrew Rule PS please tell me if I should open a new bug for some of this, I wasn't sure. But the gamma stuff seemed so similar I thought it might be the same bug. PPS: package versions: firmware-linux/testing uptodate 0.29 libc6/testing uptodate 2.11.2-11 libdrm-radeon1/testing upgradeable from 2.4.23-3 to 2.4.24-2 libdrm2/testing upgradeable from 2.4.23-3 to 2.4.24-2 libpciaccess0/testing uptodate 0.12.1-1 libpixman-1-0/testing uptodate 0.21.4-2 libudev0/testing upgradeable from 166-1 to 167-3 xserver-xorg-core/testing uptodate 2:1.9.5-1 xserver-xorg-video-radeon/testing uptodate 1:6.14.1-1 I upgraded to: firmware-linux/testing uptodate 0.29 libc6/testing uptodate 2.11.2-11 libdrm-radeon1/testing uptodate 2.4.24-2 libdrm2/testing uptodate 2.4.24-2 libpciaccess0/testing uptodate 0.12.1-1 libpixman-1-0/testing uptodate 0.21.4-2 libudev0/testing upgradeable from 166-1 to 167-3 xserver-xorg-core/testing uptodate 2:1.9.5-1 xserver-xorg-video-radeon/testing uptodate 1:6.14.1-1 with no obvious change, certainly not to the gamma issue. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk22epYACgkQAXpg5UuOD0UtzwCgmLNnarwPog1J+v6TmvAwOA3Q PC8AnjW6/ejWvwW7ewVIIMq7MZWs+J72 =NH8l -END PGP SIGNATURE- ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585777: Radeon gamma bug, display too bright when using VGA output
On Tue, Apr 26, 2011 at 4:41 PM, Andrew Rule a.r...@freeuk.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/04/11 20:39, Alex Deucher wrote: On Tue, Apr 26, 2011 at 3:56 AM, Andrew Rule a.r...@freeuk.com wrote: Hi, I also have this problem. It appeared for me when I upgraded from Xorg 1.7.x to Xorg 1.9.5 I am using ATI Radeon Mobility 9200 (M9+) 5C63 (AGP) (ChipID = 0x5c63) as X reports it, and Linux amos 2.6.38.3 #2 SMP PREEMPT Sat Apr 16 22:03:19 BST 2011 i686 GNU/Linux from kernel.org I tried setting Gamma in /etc/X11/xorg.conf, but it didn't pick it up. If I run xgamma after logging in to X, it *does* change the gamma - but still not enough. So I can set Gamma to 0.3 in the file, but if I set it using xgamma, it actually darkens the screen somewhat - but it is still not right. Output from xgamma: - Red 0.300, Green 0.300, Blue 0.300 - Red 0.300, Green 0.300, Blue 0.300 It's not the gamma, but the dac adj values. I tried radeontool regset DAC_MACRO_CNTL 0x0808 but it didn't work for me. (Perhaps that is not a surprise, I am using a tower PC, not a laptop.) You are probably using the secondary dac. The dac adjust values for the TV dac are in TV_DAC_CNTL. Perhaps I should not mention this here, but X is also unstable for me under KDE now, so I'm using sawfish for the time being. Specifically, it crashes when notifications popup in KDE. Another problem I have noticed is that when scrolling a window under another window, the contents of the lower window smudges. O, and popup hints from firefox come up in the wrong place for the search box. And, as you can see from the attached files, I am not using KMS - because I found that unstable since upgrading the kernel from 2.6.36.1 to 2.6.38.x (although previously the virtual terminals had not worked at all, and now they do occasionally; but it was stable under X, now it is not.) What is unstable with KMS? KMS is more likely to be fixed that UMS at this point. If you want to fix UMS, you'll probably have to bisect xf86-video-ati to find out what change caused the breakage. Your time would be better off spend bisecting to see what caused the instability with KMS. Alex So your saying that this problem with the dac adj values is totally dependant on whether I'm using KMS or UMS? And I should research further and report it as another bug? Or try Xorg 1.9.5 using KMS and report any bugs that happen with them? No. I'm saying UMS is slowly being deprecated, so if you are seeing a problem, KMS is more likely to get fixed. It should work fine with either KMS or UMS, but it has apparently regressed on your card at least with UMS. Alex Please ask further questions if you need. I'm gonna try downgradeing X, cos I'd like to have a screen I can look at pictures on :-) Sincerely, Andrew Rule PS please tell me if I should open a new bug for some of this, I wasn't sure. But the gamma stuff seemed so similar I thought it might be the same bug. PPS: package versions: firmware-linux/testing uptodate 0.29 libc6/testing uptodate 2.11.2-11 libdrm-radeon1/testing upgradeable from 2.4.23-3 to 2.4.24-2 libdrm2/testing upgradeable from 2.4.23-3 to 2.4.24-2 libpciaccess0/testing uptodate 0.12.1-1 libpixman-1-0/testing uptodate 0.21.4-2 libudev0/testing upgradeable from 166-1 to 167-3 xserver-xorg-core/testing uptodate 2:1.9.5-1 xserver-xorg-video-radeon/testing uptodate 1:6.14.1-1 I upgraded to: firmware-linux/testing uptodate 0.29 libc6/testing uptodate 2.11.2-11 libdrm-radeon1/testing uptodate 2.4.24-2 libdrm2/testing uptodate 2.4.24-2 libpciaccess0/testing uptodate 0.12.1-1 libpixman-1-0/testing uptodate 0.21.4-2 libudev0/testing upgradeable from 166-1 to 167-3 xserver-xorg-core/testing uptodate 2:1.9.5-1 xserver-xorg-video-radeon/testing uptodate 1:6.14.1-1 with no obvious change, certainly not to the gamma issue. ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk23LgwACgkQAXpg5UuOD0XQuwCg0mkLClLtR+UT9972+2853He9 WysAn3t87LNY02xCgB+rc26gggccn0jy =1R4y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622346:
On Tue, Apr 19, 2011 at 6:22 AM, Boris Hollas boris.hol...@gmx.de wrote: Package: xserver-xorg-video-radeon Version: 1:6.13.1-2+squeeze1 Severity: normal The problem is also present if the laptop lid is closed. If this is the intended behavior, I propose a change request: If the laptop lid is closed and an external monitor is connected, the external monitor shall be run at its native resolution. If this issue is not specific to the radeon driver, it should be filed for xorg. This is not specific to the radeon driver. It's up to the desktop environment (gnome/kde/etc.) to decide what to do when the lid is closed. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620858: slow performance continues
On Mon, Apr 4, 2011 at 8:01 PM, Andres Cimmarusti acimmaru...@gmail.com wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.0-1 Followup-For: Bug #620858 I set vblank_mode=0 using a .drirc file in my home directory. This caused the overall slow down I was only experiencing after resuming from suspend to manifest itself all the time. Framerate in glxgears was no longer in sync with refresh rate, but it was quite poor (200 fps). In the past I've gotten more like 800 fps (radeon) and 1200 (catalyst on lenny). Also, only by moving the cursor with the touchpad, causes the framerate in glxgears to drop further. gears is not a benchmark. It's highly CPU dependant. Desktop experience is quite slow. I pulled mesa 7.10.1 from experimental to see if this would help, but it didn't. The good news is that, after waking from suspend graphics performance is the same. Also I would like to correct a statement I made on my first email. Restarting X does not fix the problem (when vblank_mode is NOT set to zero). $ glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on ATI RS480 Since you are using gallium make sure it is built with llvm support as that is very important for asics without vertex hardware. You can also disable tear-free buffer swaps by adding: Option SwapbuffersWait FALSE to the device section of your xorg.conf. That coupled with vblank_mode=0 should give you maximum framerates at the expense of tearing. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]
On Sun, Mar 6, 2011 at 1:36 PM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2011-03-06 at 13:08 -0500, Alex Deucher wrote: On Fri, Mar 4, 2011 at 8:50 PM, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2011-03-04 at 21:01 +0200, Faidon Liambotis wrote: severity 616301 critical thanks No, not unless it will affect a large proportion of users. My system locks up whenever I click on a YouTube video link since yesterday. I can probably live without YouTube :), but in any case this shouldn't happen. This isn't a singled out case nor in exotic, possibly faulty, hardware. It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon HD card (one of the standard configurations) and this is on a stock squeeze system. The findings so far seem to suggest this is a Mesa issue; I'd probably file it under Linux kernel bugs (or even DoS bugs) but I'm not sure where to properly file such bugs in the post-KMS stack world. If there is a kernel driver involved then it should be assigned to the kernel. Even without KMS, a Mesa driver should be considered untrusted and should not be able to trigger a crash or hang. With KMS, this applies to the X driver too. With or without KMS, the userspace acceleration drivers can certainly cause GPU hangs if the 3D engine is programmed with some combination of commands it doesn't like. You can't solve the halting problem but you can implement a watchdog, can't you? We have lockup detection and asic reset support, but depending on the lockup it may or may not be able to successfully reset the asic. Also, as for the command buffer checking, we try to protect against basic stupidity, but the chips are just too complex to check for every possible scenario that might cause a hang. Alex Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]
On Fri, Mar 4, 2011 at 8:50 PM, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2011-03-04 at 21:01 +0200, Faidon Liambotis wrote: severity 616301 critical thanks No, not unless it will affect a large proportion of users. My system locks up whenever I click on a YouTube video link since yesterday. I can probably live without YouTube :), but in any case this shouldn't happen. This isn't a singled out case nor in exotic, possibly faulty, hardware. It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon HD card (one of the standard configurations) and this is on a stock squeeze system. The findings so far seem to suggest this is a Mesa issue; I'd probably file it under Linux kernel bugs (or even DoS bugs) but I'm not sure where to properly file such bugs in the post-KMS stack world. If there is a kernel driver involved then it should be assigned to the kernel. Even without KMS, a Mesa driver should be considered untrusted and should not be able to trigger a crash or hang. With KMS, this applies to the X driver too. With or without KMS, the userspace acceleration drivers can certainly cause GPU hangs if the 3D engine is programmed with some combination of commands it doesn't like. Alex Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615657: xserver-xorg-video-ati: xrandr --rotate kills X
On Sun, Feb 27, 2011 at 6:31 PM, Arian Sanusi ar...@sanusi.de wrote: Package: xserver-xorg-video-ati Version: 1:6.14.0-1 Severity: normal running: xrandr --output DVI-0 --rotate makes the X-Server die imediately, nothing written to log, no output when started from a VT. Graphics Processor is a Radeon HD3000 (AMD 760G). Monitors go to Stand because of no Input, the keyboard is unusable until sysrq-unraw, switching to a vt afterwards does not recover modesetting, still no Output. Starting X p.e. by starting a display manager over ssh recovers modesetting. This happens all combinations of Xorg 1.7.7 from testing, 1.9.4 from unstable, Kernel 2.6.32 from testing and 2.6.37 from unstable. However, this does not happen with Ubuntu Maverick (1.9.0 + 2.6.35) nor with gentoo (1.9.4 + 2.6.36) [ 21.248538] [drm] Loading RS780 Microcode [ 21.274940] [drm:r600_startup] *ERROR* Failed to load firmware! Install the linux firmware package. rotation requires acceleration and acceleration is not available without the firmware. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570466: it's been a month, is this still a problem?
On Tue, Feb 22, 2011 at 4:50 PM, Rémi Letot hob...@poukram.net wrote: Le 21/02/11 19:01, Cyril Brulebois a écrit : Hi Rémi, Rémi Letothob...@poukram.net (26/10/2010): I have tried that option on 2.6.36 and 2.6.32 from sid, and I haven't had a single blackout for more than one week. It could still be a coincidence since the problem is completely random, but that would be a huge one... […] I'll try to build that and use it at my next reboot. what's the status with 2.6.37-1-$arch available in sid (possibly with an up-to-date X stack in sid)? Hi, I'm tracking sid for most of the system, and experimental when available for the X stack. Since I reported the bug, the only combination that was potentially free from blackouts was with kernel 2.6.37-rc7. I say potentially because I'm not 100% sure, but I can't remember having had a blackout with that kernel. But I don't have that package anymore, so I can't verify that. I rebooted this morning to 2.6.37-1 and got several blackouts since then. The blackouts tend to disappear when uptime rises, so I don't reboot often :-) By the way, the radeon.new_pll=0 trick has not been possible with 2.6.37. As passing that option while booting used to solve the problem (or more probably hide it), has that option been renamed or is it gone ? It was removed in 2.6.37 as it always uses the old pll algo. However, there were a lot of pll fixes in 2.6.38 that should show up in the stable stream as well. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a6f9761743bf35b052180f4a8bdae4d2cc0465f6 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=51d4bf840a27fe02c883ddc6d9708af056773769 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f523f74eac1897b13c05c88ce6e5de0a7c34578b http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=619efb105924d8cafa0c1dd9389e9ab506f5425d http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a4b40d5d97f5c9ad0b7f4bf2818291ca184bb433 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5b40ddf888398ce4cccbf3b9d0a18d90149ed7ff http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9f4283f49f0a96a64c5a45fe56f0f8c942885eef Alex Thanks, -- Rémi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#437332: xserver-xorg-video-ati: Failed to detect secondary monitor, MergedFB/Clone mode disabled
On Mon, Feb 21, 2011 at 12:28 PM, Cyril Brulebois k...@debian.org wrote: Hi Alberto/Alex, Alex Deucher alexdeuc...@gmail.com (13/08/2007): Hmmm... I didn't realize you were using an XPRESS chip. multi-head is handling is not really working properly at the moment due to a lack of documentation on the XPRESS chips. could you please tell us what the status is with squeeze's or sid's X stack? I'm not sure about debian specifically, but rs4xx chips are working fine on upstream kernels and have been for a while (since kms was introduced at least). Alex KiBi. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1ioKUACgkQeGfVPHR5Nd13ogCfXirRc4jDgzrPMtAbl+mSjUl7 3jAAoJ5wOV6+MW7rDpUN0PG9zGOFcjPS =hQgc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536098: xserver-xorg-video-radeon: deterministic X lockup with dri
On Mon, Feb 21, 2011 at 12:46 PM, Cyril Brulebois k...@debian.org wrote: Hi! Alex Deucher alexdeuc...@gmail.com (08/07/2009): On Wed, Jul 8, 2009 at 8:22 AM, Jonathan Rafael Ghigliajrghig...@gmail.com wrote: I can't mess up with this computer right now. I tried the packages from unstable (7.4*) with no luck (same bug). Again, changing AGP mode has no effect, while turning on PCI mode (apparently) solves the problem, but reduces performances. In that case it could be a flakey AGP bridge on your computer. Most AGP chipsets were in one way or another. I'm not sure where to go from here. Call it a hardware bug and close this report? Jonathan, what do you think? I would suggest trying a kms enabled kernel. If you have problems try booting with radeon.agpmode=x where x = -1 or 1 or 2 or 4 or 8 on the kernel command line in grub. -1 disables agp and uses the internal gart mechanism, which should work but with reduced performance. 1-8 will change the agp mode accordingly. Alex KiBi. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1ipPYACgkQeGfVPHR5Nd3X7wCgqc8oktEk+4OJNiNZ70ye4ew8 TTMAni3CVQ8XviuEf2sifnd9ab19s9Hx =cAP6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613137: xserver-xorg-video-radeon: no video signal or kbd after manually launching X
On Mon, Feb 14, 2011 at 4:09 PM, GSR gsr.b...@infernal-iceberg.com wrote: Hi, jcris...@debian.org (2011-02-13 at 1104.39 +0100): back, the screen shows the bg (or maybe it was left from previous run) and then monitor goes into sleep immediately, ignoring kbd as original report. You should probably trim your xorg.conf down to just monitor sections to stop other stuff interfering... Spliting it into files inside xorg.conf.d/ and playing renaming game (easier to move foo.conf to foo.conf- to see what part is wrong) I found the problem of the black screen, but also issues with how things are done with outputs and config. Maybe worth new bugs? The problem line was 'FontPath unix/:7100' XFS is running, but seems that having that line in the conf makes it go nuts in unrelated ways. The left issues are: System sees an inexistant monitor on VGA connector. The cable is there, but the monitor is off and not responding (otherwise it would had seen valid vendor name, etc via DDC, right?). Even so, the system insists in giving it some random settings and keep the output fully enabled. If the driver can't detect the monitor using ddc, it uses load detection for analog monitors in case the monitor does not support ddc. In your case the connected monitor is creating a load on the connector. Also, note that monitors are supposed to keep ddc working even when the monitor is powered off, so just turning a monitor off will not general prevent the driver from seeing it. Once that monitor is configured via .conf file(s) with better Modelines than DDC ever provided, it keeps the output enabled even when the config has 'Option Enable false'. At least xrandr keeps the modelines right. IIRC, you need: Option Disable True Set DVI-0 to be primary wihth 'Option Primary true', but that one is ignored and VGA is still enabled. It is trully obsessed with having that output even if not needed and told to forget about it for now. ;] Workaround is to issue xrandr --output VGA-0 --off in ~/.xsession, so apps do not get confused with false overlapping monitors (maximize, etc). I guess this bug can be closed. Thanks for the help. GSR ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607510: Suggestion about slow radeon, debian bug 607510
On Fri, Feb 11, 2011 at 5:06 PM, Gábor Melis m...@retes.hu wrote: GSR gsr.b...@infernal-iceberg.com writes: Hi, daen...@debian.org (2011-02-11 at 1035.03 +0100): On Fre, 2011-02-11 at 05:54 +0100, GSR wrote: Could you check MigrationHeuristic setting? And try with greedy? This option doesn't have any effect with current upstream xserver and KMS, and even with older xservers where it accidentally had an effect, it's probably better to use the radeon driver option EXAPixmaps off if you want to prevent acceleration on all pixmaps other than the visible screen. Might be worth trying the current X server and driver in sid first though to see if they're doing better. With KMS 6.13.1-2+squeeze1 (Sid has 6.13.2-2, update scheduled in some days) removing MigrationHeuristic from xorg.conf gives acceptable speed, same than with it. So at some point in the past, the issue that required greedy was solved. The obvious test was 5 sec canvas refreshes in GIMP when repositioning the content. Thanks for the tip. GSR I have tested smart, greedy, exapixmaps on/off with EXA and 'options radeon modeset=0'. They don't seem to have any noticable effect with the exception of smart that made xorg segfault. Apart from that, the old konsole font still makes konsole crawl and there are noise-like artifacts on the icons in the taskbar and on window borders. Another data point is what my other, almost identical t60, does. With kms it starts to flicker randomly as if vert sync were off. Sometimes it rights itself for no apparent reason. It's unusable. Without kms there is no flicker after a day of testing. The konsole font issue is still there though. Note that the two machines have almost identical hardware: the first has a slightly faster cpu and 3945ABG wireless, the second has a slower cpu and AR5212 wireless. Furthermore, both have the same packages installed (by now they both run squeeze) and the same xorg.conf. The module list has very few differences and those are due to the different wireless cards. BIOS settings are identical, too. BIOS versions are not quite the same (2.20 and 2.26), but both are pretty recent (the second behaved the same with 2.17 that's older than 2.20). Xorg logs are pretty much the same. For the flickering, Option DisplayPriority HIGH didn't help either. There were some pll regressions in 2.6.37. Try 2.6.38-rc4 or newer. For reference: https://bugzilla.kernel.org/show_bug.cgi?id=26552 Gabor ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607227: xserver-xorg-video-radeon: with kms, screen flickers, without kms xorg eats 100% CPU
2010/12/16 Marcos Marado mindboosterno...@gmail.com: Hi there, 2010/12/16 Michel Dänzer daen...@debian.org: On Mit, 2010-12-15 at 21:29 +, Marcos Marado wrote: After installing on this machine squeeze from the debian-installer beta 2, I noticed that the screen sometimes flickers (opening a konsole an maximizing it will result in a more frequent flickering). Searching about it, I was led to believe that this could be a kms problem, so I deactivated it. Now the flicker is gone, but the computer is awefully slow, and a top shows Xorg eating 100% CPU. [...] [ 17.750916] [drm:radeon_do_init_cp] *ERROR* Failed to load firmware! [...] Versions of packages xserver-xorg-video-radeon suggests: pn firmware-linux none (no description available) Does installing this package and rebooting help for any of your problems? Thank you very much for your quick reply. I should have looked into the logs... Installed firmware-linux, and now the 100% CPU issue is gone. Unfortunately, the flickering issue (more often on black screens) is still present with kms, so for now I'm sticking with having it disabled. If you want to have doing some debugging/testing/whatever, feel free to ask... Try booting with radeon.new_pll=0 and/or radeon.disp_priority=2 on the kernel command line in grub. Alex Best regards, -- Marcos Marado ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607227: xserver-xorg-video-radeon: with kms, screen flickers, without kms xorg eats 100% CPU
On Fri, Dec 17, 2010 at 5:21 PM, Marcos Marado mindboosterno...@gmail.com wrote: Hello again, 2010/12/17 Alex Deucher alexdeuc...@gmail.com: 2010/12/16 Marcos Marado mindboosterno...@gmail.com: 2010/12/16 Michel Dänzer daen...@debian.org: On Mit, 2010-12-15 at 21:29 +, Marcos Marado wrote: After installing on this machine squeeze from the debian-installer beta 2, I noticed that the screen sometimes flickers (opening a konsole an maximizing it will result in a more frequent flickering). Searching about it, I was led to believe that this could be a kms problem, so I deactivated it. Now the flicker is gone, but the computer is awefully slow, and a top shows Xorg eating 100% CPU. [...] [ 17.750916] [drm:radeon_do_init_cp] *ERROR* Failed to load firmware! [...] Versions of packages xserver-xorg-video-radeon suggests: pn firmware-linux none (no description available) Does installing this package and rebooting help for any of your problems? Thank you very much for your quick reply. I should have looked into the logs... Installed firmware-linux, and now the 100% CPU issue is gone. Unfortunately, the flickering issue (more often on black screens) is still present with kms, so for now I'm sticking with having it disabled. Try booting with radeon.new_pll=0 and/or radeon.disp_priority=2 on the kernel command line in grub. Yup, just did one test: turned modeset on and booted with radeon.new_pll=0 and the flickering is gone. OK, this should be fixed in 2.6.37 then. Alex Feel free to ask me anything else you think it might be useful. Best regards, -- Marcos Marado -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585777: xserver-xorg-video-radeon: Radeon gamma bug still there
On Mon, Nov 22, 2010 at 9:14 PM, V. Gaibler li...@volker-gaibler.de wrote: Package: xserver-xorg-video-radeon Version: 1:6.13.1-2+squeeze1 Severity: normal The problem is still there in squeeze for graphics card Radeon Mobility X600 (lspci shows VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility X600]). Only kernel 2.6.32-5 is available (linux-image-2.6.32-5-686) and is the default chosen kernel. This might be an ugly bug in sqeeze... The fix described above, however, still works. The upstream drm fix is: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3a89b4a9ca7ce11e3b7d5119aea917b9fc29a302 Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603469: xserver-xorg-video-ati: screen randomly goes black with no way to bring it back
On Sun, Nov 14, 2010 at 8:32 AM, lauren lau...@gagfoot.com wrote: Package: xserver-xorg-video-ati Version: 1:6.13.1-2 Severity: important after some random time period my screen goes black and nothing i do short of rebooting can bring it back ... i have gotten quite good at switching to a new console and logging in and rebooting without being able to see what i'm doing btw the system is still running normally but no display at all i am using the open source ati driver with a Thinkpad T500 ... KMS is enabled and the DRM module is loading correctly Are things any better with a newer kernel? Alex -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Dec 27 2009 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1733468 Oct 10 14:03 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650 /etc/X11/xorg.conf does not exist. Kernel version (/proc/version): Linux version 2.6.32-5-686 (Debian 2.6.32-27) (m...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 22:47:19 UTC 2010 Xorg X server log files on system: -rw-r--r-- 1 root root 33504 Nov 14 13:50 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32.23-dsa-ia32 i686 Debian Current Operating System: Linux BUZZ 2.6.32-5-686 #1 SMP Sat Oct 30 22:47:19 UTC 2010 i686 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=564cf89a-18e1-46e3-acd0-159224283f2e ro quiet Build Date: 10 October 2010 11:57:07AM xorg-server 2:1.7.7-8 (Cyril Brulebois k...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Nov 14 13:50:44 2010 (==) Using system config directory /usr/share/X11/xorg.conf.d (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |--Screen Default Screen Section (0) (**) | |--Monitor default monitor (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. (II) Loader magic: 0x81ecca0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (++) using VT number 7 (--) PCI:*(0:1:0:0) 1002:9591:17aa:2117 ATI Technologies Inc Mobility Radeon HD 3650 rev 0, Mem @ 0xd000/268435456, 0xcfff/65536, I/O @ 0x2000/256, BIOS @ 0x/131072 (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: dbe (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: glx (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==)
Bug#570466: it's been a month, is this still a problem?
On Wed, Oct 13, 2010 at 3:28 PM, Rémi Letot hob...@poukram.net wrote: Le 13/10/10 20:14, Andres Cimmarusti a écrit : Have you tried kernel 2.6.35 in experimental? yes, and now I'm on 2.6.36rc6 from experimental. The blackouts tend to be less frequent, but still there. Also, try dri2 packages were recently upgraded in squeeze. However, you may also try the ones in experimental. I'm using all from sid or experimental: - mesa 7.8.2-2 - radeon 1:6.13.1-2 - drm 2.4.22-1 Hope the issue is solved I have tried every new possibly involved package when they are published in sid or experimental. But the issue is not solved. Does booting with radeon.new_pll=0 help? Alternatively, you can try Dave's drm-radeon-testing tree as it has some pll patches: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing Alex HTH, -- Rémi ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597358: xserver-xorg-video-radeon: Screen brightness flickers when KMS is enabled
On Mon, Oct 11, 2010 at 8:30 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2010-09-27 at 11:27 -0400, Alex Deucher wrote: On Mon, Sep 27, 2010 at 11:19 AM, Cyril Brulebois k...@debian.org wrote: Aaron Small aaron.small@gmail.com (26/09/2010): I'm having trouble applying these patches - the first two were able to apply, but the third patch seems to be applied to source quite different than what I have. I can't figure out how to apply it even manually. I'm using the debian linux-source-2.6.32 package, version 2.6.32-23. Is there a better kernel source I could try to apply to? Probably linux-2.6's master? Yes. Alex, how confident are you about these changes? It looks like they're going to potentially change clock setup for all Radeon chips; is that right? Yes, it will affect all radeons, but in practice it's should really only change things on avivo hw (r5xx+) due to the limited number of post dividers on pre-avivo hardware. It's the same algo that was used originally on all radeons, before I added the newer algo; the only tweak is that we prefer higher post dividers rather than lower ones. In practice, it seems the older one works better. I've tested them on a variety of monitors on all my radeon cards (r1xx-evergreen families). Additionally these patches have fixed several bugs where the newer algo did not work properly. Alex Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595767: Won't load hardware acceleration after system start
On Wed, Oct 6, 2010 at 6:17 AM, Ivan Vilata i Balaguer i...@selidor.net wrote: Cyril Brulebois (2010-10-05 19:12:12 +0200) wrote: Please install 2.6.32 kernel from sid, boot it with KMS enabled, and send both kernel X logs so that we can determine why DRI doesn't work out of the box in that case. Done. Here you have both log files. You have radeonfb loaded which is claiming the device preventing the kms drm from loading. Alex -- Ivan Vilata i Balaguer -- http://ivan.lovesgazpacho.net/ ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597636: linux-image-2.6.32-5-amd64: Unable to login with this kernel
On Sun, Sep 26, 2010 at 9:46 PM, Ben Hutchings b...@decadent.org.uk wrote:
Alex,
Moorthi Pichumani reports that radeon crashes at startup in a Debian
kernel. This has drm from 2.6.33 with backported fixes. The oops
message shows it's trying to write through a null pointer in
r600_ioctl_wait_idle(). I thought this might be due to the bug you
fixed in commit 87cbf8f drm/radeon/kms: fix a regression on r7xx AGP
due to the HDP flush fix, but this is not an AGP device. Any other
ideas?
The bug report is at http://bugs.debian.org/597636.
Our kernel source is git://git.debian.org/kernel/linux-2.6.git#squeeze.
The attached patch should fix it.
Alex
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
From 1c9b3a143a9ddd64c390dfeb757a8f6d12b70c90 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Mon, 27 Sep 2010 10:53:34 -0400
Subject: [PATCH] drm/radeon/kms: fix potential segfault in r600_ioctl_wait_idle
radeon_gem_wait_idle_ioctl can apparently get called prior to
the vram page being set up or even if accel if false, so make
sure it's valid before using it.
Should fix:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597636
https://bugs.freedesktop.org/show_bug.cgi?id=29834
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/r600.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 30a51c3..31f45af 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3491,7 +3491,8 @@ void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo *bo)
/* r7xx hw bug. write to HDP_DEBUG1 followed by fb read
* rather than write to HDP_REG_COHERENCY_FLUSH_CNTL
*/
- if ((rdev-family = CHIP_RV770) (rdev-family = CHIP_RV740)) {
+ if ((rdev-family = CHIP_RV770) (rdev-family = CHIP_RV740)
+ rdev-vram_scratch.ptr) {
void __iomem *ptr = (void *)rdev-vram_scratch.ptr;
u32 tmp;
--
1.7.1.1
Bug#597358: xserver-xorg-video-radeon: Screen brightness flickers when KMS is enabled
On Mon, Sep 27, 2010 at 11:19 AM, Cyril Brulebois k...@debian.org wrote: Aaron Small aaron.small@gmail.com (26/09/2010): I'm having trouble applying these patches - the first two were able to apply, but the third patch seems to be applied to source quite different than what I have. I can't figure out how to apply it even manually. I'm using the debian linux-source-2.6.32 package, version 2.6.32-23. Is there a better kernel source I could try to apply to? Probably linux-2.6's master? Yes. Alex Mraw, KiBi. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkygthgACgkQeGfVPHR5Nd0hegCeLowKgIyzRX2ilkbEf997DKIA VWQAn3yr0MxPh3pBrsdNJQgyVP5ldaPh =mH2w -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595767: xserver-xorg-video-radeon: Won't load hardware acceleration after system start
On Tue, Sep 7, 2010 at 6:48 AM, frank.kott...@gmx.de wrote: Hi, Make sure the radeon drm is loaded before you start X. Alex Radeon drm is loaded by xorg.conf which is loaded by X, isn't it? How can I get that to load before X starts? For KMS, the drm needs to be loaded before X starts since it fully controls the hw with KMS rather then being partially shared with the userspace driver. You need to adjust your udev or modprobe or initrd settings to make sure the module is loaded before X starts. The problem is, when the ddx attempts to load the drm, it often does not finish initializing the hardware before X starts so the ddx assumes KMS is not enabled and then both the ddx and the drm attempt to control the hardware. Alex Cheers Frank -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595767: xserver-xorg-video-radeon: Won't load hardware acceleration after system start
On Mon, Sep 6, 2010 at 10:42 AM, Julien Cristau jcris...@debian.org wrote: On Mon, Sep 6, 2010 at 16:15:44 +0200, Frank Kottler wrote: after boot, the started GUI has no enabled hardware acceleration: ~$ glxinfo | grep -i render direct rendering: Yes OpenGL renderer string: Software Rasterizer Which means, e.g., i can't start compiz. But after killing and restarting X, everything works fine: ~$ glxinfo | grep -i render direct rendering: Yes OpenGL renderer string: Mesa DRI R200 (RV250 4C66) 20090101 x86/MMX/SSE2 TCL DRI2 IMHO, that means some part of the graphical driver is loaded too late for the system to detect hardware acceleration actually IS available. Any solutuions? Make sure the radeon drm is loaded before you start X. Alex Send dmesg and X log from when that happens. Cheers, Julien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMhP3pAAoJEDEBgAUJBeQMGPUP/Rkgo+FTa8iTReWbUOSL1AKl lJK4P78KrjX8ff9+vtx4exff7skP5DiLjsOOFJefgb1Py1GYxbMix17G2G8VUla6 0CujQNsTv+m/hKRI9/409km8lI8dgWQIn/jV9gilnt5AY+xkU6z05hP1DOHlbUfi 3CSfaATYoD7vqW0P2Oa0inBtPQnfFrxwPT4sPZaC1ex4IfLcwoCU1p1Bk+UPw7FY 29dxzVvdg4k9IFsiRVSJS3mRIlAyMk4pOvVKHHBi/cjMeSdTWcpw2+6ke8teIsWt VSzV6NwzqQSW71JaQ8SypqQ4B7eKuoSdankpCKL5nRYZPT61gPTI5LzKC6WZA2V7 eHVbVj+yRhDRmU6zosdZtpeFZc1N8DVu5Ik8vSdvkncaF7rTubrvjTiZfQDxnuTt rVm34E3fFtCIthMhCB+ZZwBjTQ+deXY9mldO/No6XholETdunG2hAC9v3qf/RK01 Wrgue4UEv/xrZxXTnrGa+p0gtr6q8YgC8Hsej7Hlzi+auZNZ1dtuhrfg/IDe/JZw U+6ipdVDFtwx9l3DWaaK6JkwKqvjMVU2+gZ24dIcADbvFzWx271HeZfvM4rjt5NU noLu+uO4Na7QmQHW0wQtYRSWbkh96I/5E51OVZwjpxcBD56EiGFVy+LYP1+ebQIQ dt3mjIgzqSl/uvs70Lsb =jkQu -END PGP SIGNATURE- ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595033: xserver-xorg-video-ati: Only one display works at a time with RV620 [FirePro 2260] with two DisplayPort output
On Tue, Aug 31, 2010 at 10:59 AM, Thomas PIERSON web.pier...@gmail.com wrote: Package: xserver-xorg-video-ati Version: 1:6.13.1-2 Severity: normal Hi, I have an issue with 2 monitors connected on two DislpayPort output. The card is an ATI FirePro 2260. And only one display can works at a time. $ lspci | grep VGA 02:00.0 VGA compatible controller: ATI Technologies Inc RV620 [FirePro 2260] My issue looks like this archived bug : http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=569970 The symptoms are that only one display can be driven at a time. It also talk about two DisplayPort connections. So, the 2 monitor are connected and activated in clone mode : $ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DisplayPort-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 408mm x 255mm 1680x1050 60.0 + 1600x1200 60.0 1400x1050 60.0 1280x1024 75.0 60.0* 1440x900 59.9 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 640x400 70.0 DisplayPort-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 380mm x 305mm 1280x1024 60.0*+ 75.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 But only one display works. After that if I run for example : xrandr --output DisplayPort-0 --left-of DisplayPort-1 I have a black screen on the 2 monitors and I can't access to a terminal. I noticed something else : When I turn off and on again the second monitor (manually) an kernel error occurred : [18515.140220] [drm:radeon_process_aux_ch] *ERROR* Buffer to small for return answer 1 6 During some seconds, the main monitor get stranges color and lights intensity! It seem to be the same problem that the bug #569970 but I am not sure. Someone have an idea to solve this? Tell me if you need other logs or informations. You need this patch most likely: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5137ee940c3e593ae5578a7a12a604eb8f239ac0 which means 2.6.36rc3 or newer. Alex Regards, Thomas PIERSON ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594569: xserver-xorg-video-radeon: Unable to wake up from suspend/hiberate with RC410 [Radeon Xpress 200M]
On Fri, Aug 27, 2010 at 5:48 AM, Julien Cristau jcris...@debian.org wrote: On Fri, Aug 27, 2010 at 11:14:15 +0200, janca wrote: Kernel version (/proc/version): Linux version 2.6.32-5-686 (Debian 2.6.32-20) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Thu Aug 12 13:38:27 UTC 2010 Does 2.6.35 work better? if that doesn't work, try this patch. Also, please attach the output of lspci -vnn so I can get the subsystem pci ids. index bd74e42..0ea943a 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -3041,6 +3041,12 @@ void radeon_combios_asic_init(struct drm_device *dev) rdev-pdev-subsystem_device == 0x30a4) return; + /* quirk for rs4xx laptop to make it resume +* - it hangs on resume inside the dynclk 1 table. +*/ + if (rdev-family == CHIP_RS400) + return; + /* DYN CLK 1 */ table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE); if (table) Cheers, Julien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMd4oCAAoJEDEBgAUJBeQMN4gP/A1yoHtIWamOiSMvH48CFARW oWfYKkz1Fpxy8AsEDVJS+NhTMaqxdS1pwYVTUfkNq1MB29fyiS8dTE95e0B2arUg 2Nr/i+RrOeZsbMWlzu3/j5XsXnAuEki68+OractIlivwND32NXMaryzAoMuWvJVB 0aZfmdjgMsHWXngP7/fvqPxgpOdxLp3YFe9NwrEGR9Fwtqt+hO6rTsg4pBLOwGy7 476ef2UAV8zx8E0GHWiKs54q84XdbvbRaY/a9xRcbV11/5bMP/WEnpygYiDqYPNy kcsPzwEn5dhmLF+DPHTYyYYBsSaBlPvHfTcEm+zzh1t3GFWOzVdILo2rkSaGzmt4 /OxtoGMgskLKylLQVHxozOOuLRO3F6NnjSxs2qRkH3lnQgvpB/HQqTC3aRphhAU9 eqOvKaoq7q78K1naSCZkVYWUJ+YHv/AORYpe/ilIwrLYCeJKfAr3hmrMqgNotNvH xup9S02qeznERQ5Bc3DwJpXG0IgSNrDjvIkjXZ84/ogNYRkTi4PQTbdQsjQ9pzuc C8eWaFVCAMBKe8I+Iil2HlEKr5hI2yPS0C+fzYu8ymBaUSuPisfKCR1wRRbF1+JM 2KcGzwALj30yWV/K0YBx7zdcMBLmiCAr3cIHN05ay8UeKIH1BFarvEYkwJEEiJU4 l7cA+FbkoQopsbI2PsrL =LnKm -END PGP SIGNATURE- ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583120: Hibernate broken when KMS enabled on Radeon Mobility M6 LY
On Fri, Aug 13, 2010 at 7:54 AM, intrigeri intrig...@boum.org wrote: Hi, I have a similar problem here, same hardware. *But* I do believe this has nothing to do with xserver-xorg-video-radeon as my suspend-to-disk is also broken without X running. This looks like a kernel bug actually. Every test described bellow gives the same results, that is: - black screen then backlight on but nothing displayed - does not hibernate - no sysrq Tests: 1. runlevel 2, stopped gdm/X, rmmod ipw2200, echo disk /sys/power/state 2. single user, rmmod ipw2200, echo disk /sys/power/state 3. single user, rmmod ipw2200, start dbus, udev and hal, pm-hibernate Are you using kms? If so, does the system hibernate ok without radeon loaded? Alex Relevant packages: linux-image-2.6.32-5-686: 2.6.32-18 xserver-xorg-video-radeon: 1:6.13.1-2 xserver-xorg: 1:7.5+6 libdrm-radeon1: 2.4.18-6 libgl1-mesa-dri: 7.7.1-4 firmware-linux-nonfree: 0.26 Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | Then we'll come from the shadows. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583120: Hibernate broken when KMS enabled on Radeon Mobility M6 LY
On Fri, Aug 13, 2010 at 11:55 AM, intrigeri intrig...@boum.org wrote: Hi, Alex Deucher wrote (13 Aug 2010 15:04:49 GMT) : Are you using kms? If so, does the system hibernate ok without radeon loaded? Works ok without KMS (radeon loaded + radeon.modeset=0), does not with KMS (radeon loaded + radeon.modeset=1). I've not tried without the radeon module loaded at all. Should I? No that's fine. Can you try a newer kernel? 2.6.35.x preferably? Did hibernate ever work with kms for you? If so, what kernel version? Alex Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | Did you exchange a walk on part in the war | for a lead role in the cage? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590493: xorg-radeon: server does not start, no video output, when no screen connected
On Mon, Aug 2, 2010 at 2:07 AM, Yann Dirson ydir...@free.fr wrote: On Sun, Aug 01, 2010 at 10:12:27PM -0400, Alex Deucher wrote: On Mon, Jul 26, 2010 at 3:21 PM, Yann Dirson ydir...@free.fr wrote: Package: xserver-xorg-video-radeon Version: 1:6.13.1-2 Severity: normal Turning on my box, I see the monitor claiming no video output. Checking video cable, I see it was not fully plugged and fixed that, but got no change. Logging remotely I see (log below) that the server indeed failed to start because of this. Restarting gdm fixed the problem. It is a very unfriendly behaviour indeed. Google shows people with other video chips got a similar issue, so indeed the problem may not be specific to the radeon driver, please reassign as see fit. Unfortunately, if there is no monitor plugged in, the driver has no way of know what's connected, so it has no idea what connectors to light up. That said, in xserver 1.9, the xserver will start with a default 1024x768 framebuffer and no connected outputs, and if you are using kms and a hotplug enabled driver, you will get an event when a monitor finally gets plugged in. That's more like what I'd have expected. Can be considered fixed-upstream ? I suppose so, although only kms drivers will work properly in that scenario. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590493: xorg-radeon: server does not start, no video output, when no screen connected
On Mon, Jul 26, 2010 at 3:21 PM, Yann Dirson ydir...@free.fr wrote: Package: xserver-xorg-video-radeon Version: 1:6.13.1-2 Severity: normal Turning on my box, I see the monitor claiming no video output. Checking video cable, I see it was not fully plugged and fixed that, but got no change. Logging remotely I see (log below) that the server indeed failed to start because of this. Restarting gdm fixed the problem. It is a very unfriendly behaviour indeed. Google shows people with other video chips got a similar issue, so indeed the problem may not be specific to the radeon driver, please reassign as see fit. Unfortunately, if there is no monitor plugged in, the driver has no way of know what's connected, so it has no idea what connectors to light up. That said, in xserver 1.9, the xserver will start with a default 1024x768 framebuffer and no connected outputs, and if you are using kms and a hotplug enabled driver, you will get an event when a monitor finally gets plugged in. Alex -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 May 23 19:22 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1878240 Jun 3 17:09 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4250] /etc/X11/xorg.conf does not exist. Kernel version (/proc/version): Linux version 2.6.34.1-3-ge5b0813-dirty (r...@home) (gcc version 4.4.4 (Debian 4.4.4-6) ) #2 SMP Tue Jul 20 00:06:04 CEST 2010 Xorg X server log files on system: -rw-r--r-- 1 root root 30669 Jul 22 23:41 /var/log/Xorg.20.log -rw-r--r-- 1 root root 31448 Jul 26 20:53 /var/log/Xorg.0.log /var/log/Xorg.0.log.old: X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-5-amd64 x86_64 Debian Current Operating System: Linux home 2.6.34.1-3-ge5b0813-dirty #2 SMP Tue Jul 20 00:06:04 CEST 2010 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.34.1-3-ge5b0813-dirty root=/dev/mapper/home-root ro quiet Build Date: 03 June 2010 03:01:44PM xorg-server 2:1.7.7-2 (Julien Cristau jcris...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon Jul 26 20:47:35 2010 (==) Using system config directory /usr/share/X11/xorg.conf.d (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |--Screen Default Screen Section (0) (**) | |--Monitor default monitor (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. (II) Loader magic: 0x7c5e80 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (++) using VT number 7 (--) PCI:*(0:1:5:0) 1002:9715:1043:843e ATI Technologies Inc RS880 [Radeon HD 4250] rev 0, Mem @ 0xd000/268435456, 0xfe8f/65536, 0xfe70/1048576, I/O @ 0xb000/256 (II) Open ACPI successful (/var/run/acpid.socket) (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: dbe (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.7.7, module version
Bug#587999: further info
2010/7/6 Michel Dänzer daen...@debian.org: On Mon, 2010-07-05 at 23:14 +0200, Ulrich Eckhardt wrote: On Monday 05 July 2010 09:03:53 you wrote: On Sam, 2010-07-03 at 23:58 +0200, Ulrich Eckhardt wrote: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM [dri] Disabling DRI. It should work better with the DRI enabled. Good catch, but shouldn't it work even without DRI? It should, if someone were to fix the problem(s) with the non-DRI big endian XVideo code paths. DRI is generally desirable anyway though as it provides significantly better performance across the board. If so, please post the output of running sudo modprobe radeon as well as the messages appearing in the dmesg output after it. The module is already loaded. I can unload it though, even with a running X11 session, lsmod shows that its refcount is zero. When loading it, it outputs [drm] radeon kernel modesetting enabled. in dmesg. However, when starting the X server, it outputs radeonfb :00:10.0: Invalid ROM contents there. Looks like radeonfb is preventing the radeon kernel module from working with kernel modesetting (KMS). Disable radeonfb or load radeon with modeset=0. P.S. To fellow upstream radeon developers: In this case it would probably be more useful to initialize the DRM without KMS? Makes sense as that was the original behavior. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585822: xserver-xorg-video-radeon: radeon/KMS wrong monitor resolution due to mistakenly detected TV-out (S-video) for RV350 [Mobility Radeon 9600 M10] chipset (with workaround)
On Sun, Jun 13, 2010 at 10:39 PM, Stefano pietran...@gmail.com wrote: Package: xserver-xorg-video-radeon Version: 1:6.13.0-2 Severity: important Tags: squeeze sid *** Please type your report below this line *** Lately, I started playing with radeon/KMS (see e.g. #585815). Now, I don't know if it was because of my intervention or of a recent upgrade, but when I started my laptop the screen resolution was all messed up. I had 800x600 instead of the usual 1024x768. Looking around, I discovered that some graphic cards mistakenly detect the S-video/TV-out output as connected and set the screen resolution at 800x600. This has been disabled by default for some chipsets, but not for mine (RV350 - Mobility Radeon 9600 M10). A solution is to disable the S-video output by default at the boot. I added the kernel parameter video=SVIDEO-1:d to GRUB_CMDLINE_LINUX in /etc/default/grub and ran update-grub as root. That restores the resolution that I had before. Beware that the correct value for the video= parameter is listed in /sys/class/drm so it maight be different for other users. I have read that this option does not allow to use the S-video output, but I could not verify it (I don't use that output at all). You can still use it in X; that parameter just disables it for the console. Also, I have read that the parameter must be the last of the kernel options otherwise it won't work. Again, I have not verified that. Now, it don't know if it would be a good option to disable the S-video output for my chipset directly in the driver or to disable it using the kernel parameter. The option you used is the correct one. Unfortunately, load detection for tv-out is often unreliable. There's not a lot you can do to fix it. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583120: xserver-xorg-video-radeon: Hibernate broken when KMS enabled on Radeon Mobility M6 LY
On Tue, May 25, 2010 at 10:51 AM, Kjö Hansi Glaz k...@a4nancy.net.eu.org wrote: Package: xserver-xorg-video-radeon Version: 1:6.13.0-2 Severity: important I tested radeon KMS on a squeeze system, with xserver-xorg-video-radeon and some related packages as well as kernel 2.6.32-5 from unstable on an IBM thinkpad X32. It works quite well but it breaks suspend/hibernate. The system hangs during the suspend process, after that pm-utils write performing hibernate in its logs (all hooks succeded). I tested with and without the uswsusp package installed, which didn't changed anything. I tried to add-remove some hooks, but this was also unsuccessful. I tested the following combinaisons: --quirk-test --quirk-radeon-off --quirk-s3-bios --quirk-s3-mode --quirk-dpms-suspend --quirk-test --quirk-s3-bios --quirk-s3-mode --quirk-dpms-suspend --quirk-test --quirk-radeon-off --quirk-s3-bios --quirk-s3-mode Please try without any quirks. KMS shouldn't need them and they will likely break things. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540101: classification?
On Fri, Apr 2, 2010 at 10:40 AM, Andres Cimmarusti acimmaru...@gmail.com wrote: The overlay doesn't currently support rotation. In that case, shouldn't this bug report be classified as wishlist? Is this still true with the newer radeon drivers + kernels? For rotation you need to use the textured video adapter. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575945: exa not working with 2.6.33
On Tue, Mar 30, 2010 at 12:31 PM, Eduard Bloch bl...@debian.org wrote: Package: xserver-xorg-video-radeon Version: 1:6.12.192-2 Severity: important Hello, about a month ago, I was using radeon driver with my onboard IGP (HD4200 from 785G chipset), and kernel 2.6.32.x. The only thing I needed to set explicitely were the Option AccelMethod exa Option DRI on options and then everything (except 3D) was fine. Now I tried to use it again with 2.6.33. Result: works in 2D (less or more) but XVideo does not work at all. When KMS is enabled in the kernel module then I cannot see any reason for its breakage (log file attached). With KMS disabled, the 2D performace is a lot worse (slow repainting when moving/maximizing/switching windows) and I see a message in Xorg.0.conf telling: (WW) RADEON(0): Direct rendering is not supported when VGA arb is necessary for the device (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. I suspect you are missing the ucode needed by the chip. Make sure you have the linux-firmware package installed. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575681: xserver-xorg-video-radeon: shows severe artifacts since switching to KMS
On Sun, Mar 28, 2010 at 5:55 AM, Fabian Greffrath fabian+deb...@greffrath.com wrote: Package: xserver-xorg-video-radeon Version: 1:6.12.192-2 Severity: normal Hi, since KMS has been activated in version 1:6.12.192-2, my display shows severe artifacts. Occasionally the fonts become unreadable and some areas of the screen show a checkerboard pattern, c.f. the attached screen shot. My graphics adapter is a ATI Technologies Inc R300 AD [Radeon 9500 Pro]. Does changing the agpmode or disabling AGP help? Add: radeon.agpmode=X where X = -1, 1, 2, or 4 to the kernel command line. -1 will use pci gart rather than agp. Alex - Fabian -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Apr 9 2007 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1712808 Feb 16 09:39 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 02:00.0 VGA compatible controller: ATI Technologies Inc R300 AD [Radeon 9500 Pro] /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 932 Mar 23 20:17 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel cymotionlinux Option XkbLayout de Option XkbVariant nodeadkeys EndSection Section Device Identifier Default Screen Driver radeon # Option NoDDC true # Option DDCMode off # Option DDC off EndSection Section Monitor Identifier Configured Monitor HorizSync 60-92 VertRefresh 50-160 # Option NoDDC true # Option DDCMode off # Option DDC off # 1152x864 @ 100.00 Hz (GTF) hsync: 91.50 kHz; pclk: 143.47 MHz Modeline 1152x864_100.00 143.47 1152 1232 1360 1568 864 865 868 915 -HSync +Vsync EndSection Section Screen Identifier Default Screen Monitor Configured Monitor # DefaultDepth 24 # SubSection Display # Modes 1152x864_100.00 1280x1024 1024x768 800x600 640x480 # EndSubSection EndSection Xorg X server log files on system: -rw-r--r-- 1 root root 49356 Sep 14 2008 /var/log/Xorg.20.log -rw-r--r-- 1 root root 37583 Mar 28 11:39 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.5 Release Date: 2010-02-16 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-trunk-686 i686 Debian Current Operating System: Linux beppo 2.6.32-4-686 #1 SMP Wed Mar 17 17:16:41 UTC 2010 i686 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-4-686 root=UUID=ff43013e-d698-4d97-a4f3-aad02610d17e ro quiet Build Date: 16 February 2010 08:37:23AM xorg-server 2:1.7.5-1 (bgog...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Mar 28 11:38:57 2010 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (**) |--Screen Default Screen (0) (**) | |--Monitor Configured Monitor (==) No device specified for screen Default Screen. Using the first device section listed. (**) | |--Device Default Screen (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) Cannot locate a core pointer device. (==) |--Input Device Generic Keyboard (==) No Layout section. Using the first core keyboard device. (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Generic Keyboard (II) Loader magic: 0x81e7020
Bug#574169: xserver-xorg-video-radeon: dims display after some days of uptime
On Wed, Mar 24, 2010 at 8:36 AM, Piotr Engelking inkerma...@gmail.com wrote: I can reproduce this bug with xserver-xorg-video-radeon 1:6.12.192-1, KMS-enabled upstream stable kernel 2.6.33.1, and xscreensaver 5.10-7 by running 'xscreensaver-command -lock' in X and switching to another console before the screen finishes fading. (This requires the xscreensaver 'fade' option to be enabled, which is on by default.) After unlocking X, the screen is considerably dimmer. Running xgamma results in the following output: $ xgamma - Red 1.000, Green 1.000, Blue 1.000 $ Running 'xgamma -gamma 1' _does_ however result the screen to normal brightness. This bug may very well not be radeon-related, but I am not able to test it on another hardware at the moment - please do. (Cc-ing xscreensaver maintainers.) The fade effect done by adjusting the gamma (driver independent). The gamma isn't changed when you switch VTs. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574037: [xserver-xorg-video-radeon] OpenGL 3d games crash after a while on RV350 AP [Radeon 9600]
On Mon, Mar 15, 2010 at 5:43 PM, Matej Zary magez.ma...@gmail.com wrote: Package: xserver-xorg-video-radeon Version: 1:6.12.5-1 Severity: normal --- Please enter the report below this line. --- OpenGL 3D games like UrbanTerror or Unreal Tournament crash after while with these lines: drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream. See dmesg for more info. Signal: SIGSEGV [segmentation fault] Aborting. Segmentation fault These should be fixed in these upstream commits: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=7a9f0dd9c49425e2b0e39ada4757bc7a38c84873 http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=b4fe945405e477cded91772b4fec854705443dd5 Alex $dmesg [ 322.305400] [drm] Num pipes: 1 [ 372.981310] ut-bin: page allocation failure. order:4, mode:0x40d0 [ 372.981320] Pid: 2120, comm: ut-bin Not tainted 2.6.32-3-686 #1 [ 372.981325] Call Trace: [ 372.981346] [c108c3d3] ? __alloc_pages_nodemask+0x476/0x4e0 [ 372.981355] [c108c449] ? __get_free_pages+0xc/0x17 [ 372.981363] [c10ae931] ? __kmalloc+0x30/0x128 [ 372.981404] [e0fd5b9f] ? radeon_cp_cmdbuf+0x111/0x121e [radeon] [ 372.981416] [c101c484] ? do_page_fault+0x271/0x287 [ 372.981423] [c101c213] ? do_page_fault+0x0/0x287 [ 372.981435] [c125e8c3] ? error_code+0x73/0x78 [ 372.981465] [e17b] ? atom_rv515_force_tv_scaler+0xdb9/0x2ad2 [radeon] [ 372.981479] [c1136580] ? copy_from_user+0x104/0x10e [ 372.981498] [e0fce75d] ? radeon_commit_ring+0x47/0x91 [radeon] [ 372.981518] [e0fd75a5] ? radeon_cp_texture+0x859/0x87f [radeon] [ 372.981540] [e09e0472] ? drm_ioctl+0x89/0x268 [drm] [ 372.981554] [e09e05bb] ? drm_ioctl+0x1d2/0x268 [drm] [ 372.981574] [e0fd5a8e] ? radeon_cp_cmdbuf+0x0/0x121e [radeon] [ 372.981582] [c1007f61] ? sched_clock+0x5/0x7 [ 372.981592] [c10482ff] ? sched_clock_local+0x15/0x11b [ 372.981606] [c1025938] ? update_curr+0x106/0x1b3 [ 372.981616] [c1020768] ? sched_slice+0x67/0x7f [ 372.981623] [c1046698] ? hrtimer_forward+0x10c/0x124 [ 372.981634] [c102e73e] ? scheduler_tick+0xd3/0x1ec [ 372.981644] [c10bd501] ? vfs_ioctl+0x49/0x5f [ 372.981651] [c10bda68] ? do_vfs_ioctl+0x4aa/0x4e5 [ 372.981661] [c106f2c5] ? __rcu_process_callbacks+0x6c/0x227 [ 372.981669] [c106f4b3] ? rcu_process_callbacks+0x33/0x39 [ 372.981678] [c1035d3b] ? __do_softirq+0x115/0x151 [ 372.981685] [c10bdae4] ? sys_ioctl+0x41/0x58 [ 372.981694] [c10031dc] ? syscall_call+0x7/0xb [ 372.981699] Mem-Info: [ 372.981703] DMA per-cpu: [ 372.981707] CPU 0: hi: 0, btch: 1 usd: 0 [ 372.981711] Normal per-cpu: [ 372.981715] CPU 0: hi: 186, btch: 31 usd: 0 [ 372.981725] active_anon:29573 inactive_anon:37882 isolated_anon:6 [ 372.981728] active_file:22348 inactive_file:23447 isolated_file:0 [ 372.981731] unevictable:2 dirty:31 writeback:80 unstable:0 [ 372.981733] free:1849 slab_reclaimable:2142 slab_unreclaimable:1220 [ 372.981736] mapped:13266 shmem:89 pagetables:711 bounce:0 [ 372.981751] DMA free:2072kB min:84kB low:104kB high:124kB active_anon:2852kB inactive_anon:3800kB active_file:1444kB inactive_file:5712kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15868kB mlocked:0kB dirty:0kB writeback:0kB mapped:48kB shmem:0kB slab_reclaimable:36kB slab_unreclaimable:4kB kernel_stack:0kB pagetables:8kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 372.981764] lowmem_reserve[]: 0 492 492 492 [ 372.981780] Normal free:5324kB min:2792kB low:3488kB high:4188kB active_anon:115440kB inactive_anon:147728kB active_file:87948kB inactive_file:88076kB unevictable:8kB isolated(anon):24kB isolated(file):0kB present:503872kB mlocked:8kB dirty:124kB writeback:320kB mapped:53016kB shmem:356kB slab_reclaimable:8532kB slab_unreclaimable:4876kB kernel_stack:1464kB pagetables:2836kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 372.981794] lowmem_reserve[]: 0 0 0 0 [ 372.981801] DMA: 2*4kB 2*8kB 2*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2072kB [ 372.981820] Normal: 1017*4kB 61*8kB 10*16kB 1*32kB 7*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5324kB [ 372.981838] 46406 total pagecache pages [ 372.981842] 516 pages in swap cache [ 372.981846] Swap cache stats: add 3470, delete 2954, find 303/393 [ 372.981851] Free swap = 519900kB [ 372.981854] Total swap = 530136kB [ 372.988490] 131056 pages RAM [ 372.988497] 0 pages HighMem [ 372.988500] 2369 pages reserved [ 372.988503] 79440 pages shared [ 372.988506] 101416 pages non-shared [ 374.229712] [drm] Num pipes: 1 [ 374.326107] ut-bin[2120]: segfault at bec ip b736e9e7 sp bffbce70 error 4 in Core.so[b72f7000+af000] Can attach more of these dmesg outputs if needed. $lspci 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and
Bug#572311: No display output from Radeon RV610 on Alpha
On Sat, Mar 13, 2010 at 3:57 AM, Michael Cree mc...@orcon.net.nz wrote:
On 13/03/10 06:57, Alex Deucher wrote:
On Fri, Mar 12, 2010 at 4:57 AM, Michael Creemc...@orcon.net.nz wrote:
On 10/03/10 08:44, Alex Deucher wrote:
On Sun, Mar 7, 2010 at 3:47 AM, Michael Creemc...@orcon.net.nz
wrote:
Thanks, that hint was helpful. I have drummed up a patch
(attached)
that
replaces some use of the UINT16LE_TO_CPU(), etc., macros with
generic
interfaces from the Xserver's compiler.h header file. Now works
correctly
on RV610 video card on an Alpha XP1000. Have also verified that
the
driver
still works on an RV710 card on AMD64 architecture.
Can you add the alignment stuff to the ATOM_BSWAP16/32 functions in
radeon_atombios.c?
e.g.,
return ldw_u(bswap_16(x));
That's a good idea, however I think the ldw_u() must be inside the byte
swap
as the (mis)alignment issues must be dealt with at the point of loading
the
datum, whereas endianess can be fixed later.
Attached is a new patch that uses the ldw_u() macros and also leaves the
UINT16LE_TO_CPU, etc., macros in place. Verified working on Alpha and
AMD64
architectures, but I don't have a suitable big-endian machine to test
this.
Wouldn't it be cleaner to just put the ldw_u() in ATOM_BSWAP16()?
--- a/src/radeon_atombios.c
+++ b/src/radeon_atombios.c
@@ -28,6 +28,7 @@
#endif
#include xf86.h
#include xf86_OSproc.h
+#include compiler.h
#include radeon.h
#include radeon_reg.h
@@ -2981,7 +2982,7 @@
atombios_get_command_table_version(atomBiosHandlePtr atomBIOS, int
index, int *m
UINT16 ATOM_BSWAP16(UINT16 x)
{
- return bswap_16(x);
+ return bswap_16(ldw_u(x));
}
No, that won't work for two reasons:
1) It's only in the big endian code path. There are little endian
architectures that need the ldw_u().
2) ldw_u()'s argument is a pointer (i.e. the address from which the word is
to be loaded) not a value. This is also the reason that I didn't include
the ldw_u()s in the UINT16LE_TO_CPU, etc., macro definitions in Decoder.h.
Those macros sometimes wrap an access via a pointer and at other times they
wrap an actual value. Use of ldw_u() is only appropriate at the actual
access of a datum from the AtomBios, i.e., those cases that perform an
access through a pointer.
Thanks, I've gone ahead and pushed it to master and 6.12-branch.
Alex
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573849: xserver-xorg-video-radeon: Be verbose about discarding modes
On Sun, Mar 14, 2010 at 7:50 AM, Bas Wijnen wij...@debian.org wrote: Package: xserver-xorg-video-radeon Version: 6.12.5-1 Severity: wishlist Since fairly recently (a few months, I think), by Radeon refuses to set my monitor to 1600x1200. Looking at the server log, I found (in random order): (II) RADEON(0): #6: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEON(0): Modeline 1600x1200x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 31 H max: 81 kHz, PixClock max 170 MHz (II) RADEON(0): Not using mode 1600x1200 (mode clock too high) This makes no sense. It should be able to go up to 170 MHz, but it refuses 162 MHz. In the source I found: /* clocks over 135 MHz have heat issues with DVI on RV100 */ if ((radeon_output-MonType == MT_DFP) (info-ChipFamily == CHIP_FAMILY_RV100) (pMode-Clock 135000)) return MODE_CLOCK_HIGH; This explains why it refuses the mode. Looking at the source should not be required for understanding the log file. Please make it more readable by adding a line about the heat issues. It may also be a good idea to allow overriding the check. I never had any trouble using 1600x1200 with this card and monitor. You can start the xserver with higher verbosity levels and it will tell you why modes were rejected. You can also manually specify modelines in your xorg.conf or at run time using xrandr to override what the driver/xserver's selections. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573849: xserver-xorg-video-radeon: Be verbose about discarding modes
On Sun, Mar 14, 2010 at 2:32 PM, Bas Wijnen wij...@debian.org wrote: On Sun, Mar 14, 2010 at 10:21:02AM -0500, Alex Deucher wrote: /* clocks over 135 MHz have heat issues with DVI on RV100 */ if ((radeon_output-MonType == MT_DFP) (info-ChipFamily == CHIP_FAMILY_RV100) (pMode-Clock 135000)) return MODE_CLOCK_HIGH; This explains why it refuses the mode. Looking at the source should not be required for understanding the log file. Please make it more readable by adding a line about the heat issues. It may also be a good idea to allow overriding the check. I never had any trouble using 1600x1200 with this card and monitor. You can start the xserver with higher verbosity levels and it will tell you why modes were rejected. I didn't test, but looking at the source I find it hard to believe that there will be more information than mode clock too high. After all, the rejecting code (which I quoted above) doesn't provide any more information than that. yeah, that's what it will tell you, but I that's all you should need. You can also manually specify modelines in your xorg.conf or at run time using xrandr to override what the driver/xserver's selections. That might work, but I'm not sure. This is the code when a modeline is already present (in this case it's a default modeline), and is checked for validity. I expect that check to be performed when specifying it manually as well. But I didn't test, because I recompiled the package with the check removed, and so I have a workaround already. It will work. The point of manual modelines is that you can use them to override what the driver/xserver decides or to add modes that may not be in your monitor's edid. If you specify one, then presumably you know what you are doing. Running TMDS above 135 Mhz on those cards is out of spec, so you are on your own, it might work for you, but will not work for others (in fact the check was added as a bug fix). Alex Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkudOdUACgkQFShl+2J8z5UqUQCgi4EPrlPC07IPeA7bYJAO+qbT AQ4AoK3FIZp1oqj4XBFo+dCVHb+IFW1u =MOx4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573849: xserver-xorg-video-radeon: Be verbose about discarding modes
On Sun, Mar 14, 2010 at 2:50 PM, Bas Wijnen wij...@debian.org wrote: On Sun, Mar 14, 2010 at 02:46:15PM -0500, Alex Deucher wrote: I didn't test, but looking at the source I find it hard to believe that there will be more information than mode clock too high. After all, the rejecting code (which I quoted above) doesn't provide any more information than that. yeah, that's what it will tell you, but I that's all you should need. It now says The maximum I can handle is 170 MHz, this mode is 162 MHz, I can't handle this one because the clock is too high. It doesn't make sense. ;-) Well, the monitor says it can handle a max of 170 Mhz, but in this case, the gpu cannot. It can be a bit confusing. Alex You can also manually specify modelines in your xorg.conf or at run time using xrandr to override what the driver/xserver's selections. It will work. The point of manual modelines is that you can use them to override what the driver/xserver decides or to add modes that may not be in your monitor's edid. If you specify one, then presumably you know what you are doing. Ok, that sounds good. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkudPgEACgkQFShl+2J8z5VCBgCgyVxTHc8ncXOOklU+OH0haUJh c+QAoL6sCA5cJOaHoa2+3jOibgu392US =PEo7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572311: No display output from Radeon RV610 on Alpha
On Fri, Mar 12, 2010 at 4:57 AM, Michael Cree mc...@orcon.net.nz wrote:
On 10/03/10 08:44, Alex Deucher wrote:
On Sun, Mar 7, 2010 at 3:47 AM, Michael Creemc...@orcon.net.nz
wrote:
Thanks, that hint was helpful. I have drummed up a patch (attached)
that
replaces some use of the UINT16LE_TO_CPU(), etc., macros with generic
interfaces from the Xserver's compiler.h header file. Now works
correctly
on RV610 video card on an Alpha XP1000. Have also verified that the
driver
still works on an RV710 card on AMD64 architecture.
Can you add the alignment stuff to the ATOM_BSWAP16/32 functions in
radeon_atombios.c?
e.g.,
return ldw_u(bswap_16(x));
That's a good idea, however I think the ldw_u() must be inside the byte swap
as the (mis)alignment issues must be dealt with at the point of loading the
datum, whereas endianess can be fixed later.
Attached is a new patch that uses the ldw_u() macros and also leaves the
UINT16LE_TO_CPU, etc., macros in place. Verified working on Alpha and AMD64
architectures, but I don't have a suitable big-endian machine to test this.
Wouldn't it be cleaner to just put the ldw_u() in ATOM_BSWAP16()?
--- a/src/radeon_atombios.c
+++ b/src/radeon_atombios.c
@@ -28,6 +28,7 @@
#endif
#include xf86.h
#include xf86_OSproc.h
+#include compiler.h
#include radeon.h
#include radeon_reg.h
@@ -2981,7 +2982,7 @@
atombios_get_command_table_version(atomBiosHandlePtr atomBIOS, int
index, int *m
UINT16 ATOM_BSWAP16(UINT16 x)
{
-return bswap_16(x);
+return bswap_16(ldw_u(x));
}
UINT32 ATOM_BSWAP32(UINT32 x)
Alex
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572311: No display output from Radeon RV610 on Alpha
On Tue, Mar 9, 2010 at 2:35 PM, Michael Cree mc...@orcon.net.nz wrote: On 10/03/10 05:17, Matt Turner wrote: On Mon, Mar 8, 2010 at 6:30 PM, Michael Creemc...@orcon.net.nz wrote: On 9/03/2010, at 5:41 AM, Alex Deucher wrote: On Sun, Mar 7, 2010 at 3:47 AM, Michael Creemc...@orcon.net.nz wrote: Thanks, that hint was helpful. I have drummed up a patch (attached) that replaces some use of the UINT16LE_TO_CPU(), etc., macros with generic interfaces from the Xserver's compiler.h header file. Now works correctly on RV610 video card on an Alpha XP1000. Have also verified that the driver still works on an RV710 card on AMD64 architecture. The patch applies cleanly against the 6.12.5 branch and also upstream git master. Alex: may I presume that you will handle getting it upstream for review and hopefully acceptance into the fdo git master. I'll take a look at it. My only concern would be making sure these changes don't break big endian which is the reason the macros were added in the first place. It should work, but worth running a check. My understanding is that the ldw_u(), etc., macros/functions in compiler.h are supposed to handle all architectural issues, including endianess, alignment, and certain hardware limitations on byte/word access. I'm not sure they cover endianness. I cleaned them up last summer--there are no #ifdef BIGENDIANs in there. Bother, it looks like you are right. On re-looking at compiler.h I now see that there is only one definition of them and it doesn't appear to address endianess. Double bother! Can you add the alignment stuff to the ATOM_BSWAP16/32 functions in radeon_atombios.c? e.g., return ldw_u(bswap_16(x)); etc. Alex So what do you recommend we use to access the AtomBios that will handle both endianess and alignment issues? The alignment issue on Alpha only occurs when one can't use BWX instructions which is the case for Debian as it is compiled for generic Alpha architecture. Could we use the MMIO_IN/OUT routines and pass the address as the base and a zero offset? Cheers Michael. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572311: No display output from Radeon RV610 on Alpha
On Sun, Mar 7, 2010 at 3:47 AM, Michael Cree mc...@orcon.net.nz wrote: On 07/03/10 03:34, Alex Deucher wrote: On Fri, Mar 5, 2010 at 8:10 PM, Michael Creemc...@orcon.net.nz wrote: If I compile the ati/radeon video driver from fdo git master (commit 4975658f05) with default CFLAGS (i.e. no byte-word extension), except for the module src/AtomBios/CD_Operations.c which I compile with the -mbwx compiler option, then I get a working video driver. Looks like the problem is in src/AtomBios/CD_Operations.c. You probably need something like this drm patch ported to the ddx: http://marc.info/?l=dri-develm=126611019424637w=2 Thanks, that hint was helpful. I have drummed up a patch (attached) that replaces some use of the UINT16LE_TO_CPU(), etc., macros with generic interfaces from the Xserver's compiler.h header file. Now works correctly on RV610 video card on an Alpha XP1000. Have also verified that the driver still works on an RV710 card on AMD64 architecture. The patch applies cleanly against the 6.12.5 branch and also upstream git master. Alex: may I presume that you will handle getting it upstream for review and hopefully acceptance into the fdo git master. I'll take a look at it. My only concern would be making sure these changes don't break big endian which is the reason the macros were added in the first place. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#462582: xserver-xorg-video-ati: regression, size configuration incredibly broken, on bog-standard display size
On Sun, Mar 7, 2010 at 5:03 AM, Brice Goglin brice.gog...@ens-lyon.org wrote: On Fri, Jan 25, 2008 at 09:33:48PM +0100, Andreas Mohr wrote: Package: xserver-xorg-video-ati Version: 1:6.7.197-1 Severity: important Hi, my 14(!) VGA-connected 1024x768 _desktop_ LCD was working just fine with my config file on 1:6.6.193, however both 1:6.7.197-1 and 6.7.198~git20080117.6bd510a2 manage to mess up size detection in a spectacularly awful way, it seems (either with or without xorg.conf). - there are 12 references to 1024x768 resolution in the log (DDC detection etc.), however it chooses to pick 1280x800 which has never been announced _anywhere_! - the DPI calculations are not WAY off as in another Debian bug report, they're rather very extremely off (147, 145 instead of 89, 92 previously) The display size detection of 290x210mm seems _correct_ since it matches physical dimensions. Do you still have these problems with latest packages in unstable? FWIW, the DPI calculation is all handled in the xserver. All the driver does is pass along the EDID if there is one. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572311: No display output from Radeon RV610 on Alpha
On Fri, Mar 5, 2010 at 8:10 PM, Michael Cree mc...@orcon.net.nz wrote: If I compile the ati/radeon video driver from fdo git master (commit 4975658f05) with default CFLAGS (i.e. no byte-word extension), except for the module src/AtomBios/CD_Operations.c which I compile with the -mbwx compiler option, then I get a working video driver. Looks like the problem is in src/AtomBios/CD_Operations.c. You probably need something like this drm patch ported to the ddx: http://marc.info/?l=dri-develm=126611019424637w=2 Alex Cheers Michael. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569098: xserver-xorg-video-radeon: Xvideo apparently not working with KMS enabled
On Wed, Feb 10, 2010 at 2:00 PM, Andreas Rottmann a.rottm...@gmx.at wrote: Alex Deucher alexdeuc...@gmail.com writes: From your log: (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS Check your dmesg. You are probably missing the rlc ucode for the interrupt controller. Indeed. I've now downloaded and installed the ucode from http://people.freedesktop.org/~agd5f/radeon_ucode/ as in indicated by Bug #565437. However I still get the same results from xvinfo and mplayer. You need to make sure the kms drm is loaded before X starts. X is trying to load it but bailing before it's loaded. You may need to add radeon to your modprobe config to make sure it's loaded before X starts. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569098: xserver-xorg-video-radeon: Xvideo apparently not working with KMS enabled
On Tue, Feb 9, 2010 at 8:05 PM, Andreas Rottmann a.rottm...@gmx.at wrote: Package: xserver-xorg-video-radeon Version: 1:6.12.99+git20100201.a887818f-1 Severity: normal mplayer says this: ... [VO_XV] It seems there is no Xvideo support for your video card available. [VO_XV] Run 'xvinfo' to verify its Xv support and read ... And xvinfo gives: X-Video Extension version 2.2 screen #0 no adaptors present From your log: (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS Check your dmesg. You are probably missing the rlc ucode for the interrupt controller. Alex -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Jul 4 2008 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1864832 Jan 21 00:37 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-rw-rw- 1 root root 1924 Feb 10 01:34 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section ServerLayout Identifier Default Layout Screen 0 Default Screen 0 0 EndSection Section ServerFlags Option DontZap false EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us_de Option XkbOptions ctrl:nocaps EndSection Section InputDevice Identifier Configured Mouse Driver mouse EndSection Section Monitor Identifier Samsung SyncMaster 24' Option VendorName Samsung Option ModelName SyncMaster Option DPMS true DisplaySize 517 291 EndSection Section Device Identifier Onboard Radeon Driver radeon Option AccelMethod EXA # default shadowfb Option DRI on # Driver fglrx ## Option EnableMonitor crt1,lvds,tv,tmds1,crt2,tmds2,cv,tmds2i BusID PCI:1:5:0 # Option IgnoreEDID # Option NoDCC # Option NoRandR # Option FixPanelSize EndSection Section Screen Identifier Default Screen Device Onboard Radeon # Monitor Samsung SyncMaster 24' DefaultDepth 24 SubSection Display Viewport 0 0 Depth 24 EndSubSection EndSection Xorg X server log files on system: -rw-r--r-- 1 root root 50018 Sep 22 2008 /var/log/Xorg.20.log -rw-r--r-- 1 root root 54261 Oct 22 21:22 /var/log/Xorg.2.log -rw-r--r-- 1 root root 32431 Jan 12 15:23 /var/log/Xorg.1.log -rw-r--r-- 1 root root 32781 Feb 10 01:50 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.4 Release Date: 2010-01-08 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32.4-dsa-amd64 x86_64 Debian Current Operating System: Linux delenn 2.6.33-rc7-vanilla-amd64 #2 SMP Mon Feb 8 16:41:58 CET 2010 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.33-rc7-vanilla-amd64 root=/dev/mapper/delenn-root ro quiet Build Date: 20 January 2010 11:36:07PM xorg-server 2:1.7.4-2 (bui...@brahms.debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Wed Feb 10 01:50:54 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor default monitor (**) | |--Device Onboard Radeon (==) No monitor specified for screen Default Screen. Using a default monitor configuration. (**) Option DontZap false (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry
Bug#565313: dimmed screen with 16-bit depth using radeon driver
On Sat, Jan 30, 2010 at 10:04 PM, Alexander Sosedkin m...@unboiled.info wrote: Same regression for me, notebook is fujitsu p1120, video card is reported as ATI Technologies Inc Radeon Mobility M6 LY. Everything is dimmed and the color is definitely broken, looks like it was been repacked from R5G6B5 to R8G8B8 without scaling it, so 1 11 1 became 0001 0011 0001. I may be wrong though. Changing depth to 24 bit works for me. Sorry for not attaching any logs or configs. I think this is an xserver regression, what xserver are you using? Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550637: xserver-xorg-video-radeon: with dri enabled, the whole desktop flickers if tmw is started
On Sun, Oct 11, 2009 at 2:44 PM, Patrick Matthäi pmatth...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julien Cristau schrieb: On Sun, Oct 11, 2009 at 20:05:04 +0200, Patrick Matthäi wrote: I do not know when this issue appeared, because I didn't played the game since a longer time.. I am using kde4, sid, i386 and amd64 and radeon dri on my mobile x1250 and sapphire x1650 pro. If I start tmw windows and have got it in the foreground, my whole display begins to flicker, not only the game window. If I start it in fullscreen it seems to be quite better, but not perfect. Have you tried disabling kwin GL compositing? DRI1 with a compositing manager has never been a good combination. It is permament disabled here. Does: Option DisplayPriority HIGH in the device section of your config help? You need to use xf86-video-ati git master for this option to have an affect on your chipsets. Alex - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrSJ6cACgkQ2XA5inpabMe8ZgCgqRllSsFexTJE8FaNQwUgUvYr 0AEAn1//ZJ89Mm+b4tDpsc1b2iEO6B/O =NW+f -END PGP SIGNATURE- ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533129: xserver-xorg-video-radeon: Frequent display corruption after suspend/resume on Mobility M6 LY
On Fri, Oct 9, 2009 at 7:30 PM, Stefan Ott ste...@ott.net wrote: Hey Sorry for the late response. I just wanted to let you know that the problem is still there with version 6.12.2-1~lenny1. can you try xf86-video-ati git master? Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546588: xserver-xorg-video-radeon: Display very slow
On Sun, Sep 20, 2009 at 10:01 AM, Kjö Hansi Glaz k...@a4nancy.net.eu.org wrote: Package: xserver-xorg-video-radeon Version: 1:6.12.3-1 Severity: normal I think I experience the same problem, despite that I have firmware-linux installed. Display became slower and uses a lot of CPU since the upgrade. You GPU has very limited vram so EXA may not perform well without a decent memory manager. Try XAA for now: Option AccelMethod XAA in the device section of your xorg config. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545040: xserver-xorg-video-radeon: freeze with AGP8x on RV280 based card (AGP4x works)
On Fri, Sep 4, 2009 at 11:37 AM, Michael Stahlinan...@web.de wrote: Package: xserver-xorg-video-radeon Version: 1:6.9.0-1+lenny4 Severity: important my system running lenny, with a VIA KT400 chipset and a Asus RV280 based card, freezes hard with the default AGP8x mode. changing it to AGP4x via xorg.conf helps; no lock up so far. so it seems i need a quirk entry in the AGP mode table in the radeon driver. Quirk pushed to master and stable 6.12-branch. Thanks! Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544754: xserver-xorg-video-radeon: DRI does't work: fail to load firmware RS690. And instability when install firmware-linux package.
On Wed, Sep 2, 2009 at 3:09 PM, Brice Goglinbrice.gog...@ens-lyon.org wrote: Thomas Pierson wrote: Why the firmware-linux package is not include with the xserver-xorg-video-radeon package? The firmware is non-free, so it can't go in Debian main packages (where the video-radeon package is). Also the firmware originally comes from the kerneland not from the radeon driver anyway (the kernel is loading the firmware when needed, the user-space X driver doesn't know about it) . Is this instability result of a actual development or a bad configuration/association between these 2 package? Is my configuration correct? You don't have any xorg.conf configuration file, so there's nothing wrong with it :) There's no incompatibility between firmware-linux and the radeon driver. But installing the former enables DRI in the latter. So you get more chances of using some code that's not very stable yet. I don't know if DRI for RS690 is supposed to be stable nowadays, I hope Alex will answer this. Yes DRI on rs690 is stable. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481529: xserver-xorg-video-radeon: (strange?) workaround for video not synced
On Sun, Aug 16, 2009 at 6:22 AM, Dimitri Chaussontri2...@gmx.net wrote: Package: xserver-xorg-video-radeon Version: 1:6.9.0-1+lenny4 Severity: normal *** Please type your report below this line *** Hello, The symptoms I had were: I was forced to explicitly switch off DRI b/c the screen was not readable anymore. I have now 3 items: - By chance I discovered that when switching back to text console and back again to X solved the problem. The screen is readable again ! I cannot explain it, but maybe some of you guys have an idea? So I removed the line 'Option DRI off from my config. - I applied the trick from bug 449211. Setting this DisplayPriority option to BIOS has the positive effect that the screen is readable without having to switch back and forth from text mode. So this option seems to be useful for me (note I am using the same card : 9200 SE) - However, DRI is still disabled (automatically), and I have no clue why... Any help would be greatly appreciated. I propose to file another bug no DRI with radeon 9200 SE, or is there a more appropriate subject ? Can you post your dmesg? Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541235: xserver-xorg-video-ati: Random Lockups when DRI enabled
2009/8/17 Stefano pietran...@gmail.com: On Thu, 2009-08-13 at 11:01 +0200, Michel Dänzer wrote: Hmm. One thing I notice is that there's almost no EXA offscreen memory, due to your enormous Virtual directive. Normally this should only affect performance, not correctness, but it might be worth trying a smaller maximum desktop size just in case. Hello, I tried different configurations for my Virtual screen. Here are the logs (hope I've picked the right lines!): Virtual: 2944x1848 (BIG) (II) EXA(0): Offscreen pixmap area of 786432 bytes VirtuaL: NONE (II) EXA(0): Offscreen pixmap area of 11436032 bytes Virtual: 1920x1848 (VERTICAL) (II) EXA(0): Offscreen pixmap area of 12255232 bytes VirtuaL: 2944x1080 (HORIZONTAL) (II) EXA(0): Offscreen pixmap area of 14352384 bytes I thought that the configuration with most free memory would have been the second one (no virtual screen) but surprisingly to me it is not the case. By default xrandr 1.2 grabs a square framebuffer so rotation will work (e.g., 1920x1920). Now I'm using the 2944x1080 (HORIZONTAL) Virtual screen with AGPMode 4 (default) and DRI enabled. The issues I had seem to be gone. However I cannot activate Compositing when I use my external screen since X consumes almost the 80% of the CPU when I move the windows around the screen. If I use my laptop monitor (1024x768) Compositing works quite well, although I experienced some lock-ups when I tried to modify the options of gnome-do in order to activate the Docky. Your desktop is larger than the coordinate limits of the texture engine so it's likely falling back to software. Can we consider this bug closed? Yes. Can you do anything to prevent users to make the same mistakes I made? radeon KMS (kernel modesetting) includes a unified memory manager that will allow you to resize your desktop on the fly without needing to add the virtual stuff. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541235: xserver-xorg-video-ati: New unexpected lock-ups
2009/8/18 Stefano pietran...@gmail.com: Package: xserver-xorg-video-ati Version: 1:6.12.2-3 Severity: important Hello, when I thought that everything was fine I had again these annoying lock-ups and had to disable DRI. Since nothing has changed so far I wonder why the lock-ups are back. Yesterday night I just used my laptop with the battery and WiFi (usually I remove the battery and plug it and I use an ethernet cable) to check my emails and the X servers did not respond after about 30 seconds it had been started. Today I tried with/without battery and/or WiFi with no success. Are you still getting the lockups even with the dri disabled? Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
