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 do
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 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 "1400x1050"x0.0 108.00 1400 1448 1560 > 1688 1050 1051 1054 1066 -hsync -vsync (64.0 kHz eP) > [19.372] (II) VESA(0): Modeline "1400x1050"x0.0 89.97 1400 1
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 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 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 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 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 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 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, Владимир Титов 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 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:18 PM, Robert Millan 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#732514: [PATCH] fixes for Radeon KMS on kFreeBSD
On Wed, Dec 18, 2013 at 4:09 PM, 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. 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#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 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 Wed, Apr 3, 2013 at 2:22 PM, Pablo Oliveira wrote: > On Wed, Apr 3, 2013 at 3:34 PM, Alex Deucher wrote: >> >> On Tue, Apr 2, 2013 at 10:04 AM, Pablo Oliveira 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#529178: xserver-xorg-video-ati: Suffering from this bug + Possible mitigation
On Tue, Apr 2, 2013 at 10:04 AM, Pablo Oliveira 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#698503: tearing with Radeon HD 6970
On Sat, Jan 19, 2013 at 8:59 AM, Marc Dequènes 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 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 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 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 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 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 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
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 replaced with the apropriate
> native resolution:
>
> "The current input timing is not supported by the monitor display. Please
> change your input timing to 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 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 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 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 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 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 >> > 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 >> > 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 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 > 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 > 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 Mon, Nov 14, 2011 at 9:34 AM, Joost Kraaijeveld 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#648598: Gnome3: complete system freeze, fallback OK
On Sun, Nov 13, 2011 at 5:26 AM, Joost Kraaijeveld 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#648222: Significant 2D performance regression with ColorTiling
On Sun, Nov 13, 2011 at 1:34 PM, Iustin Pop 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 wrote: >> > > On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop 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 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 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 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 [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 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 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 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 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 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/2 Lisandro Damián Nicanor Pérez Meyer : > 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#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 : > 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#585777: Radeon gamma bug, display too bright when using VGA output
On Tue, Apr 26, 2011 at 4:41 PM, Andrew Rule 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 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#585777: Radeon gamma bug, display too bright when using VGA output
On Tue, Apr 26, 2011 at 3:56 AM, Andrew Rule 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#622346:
On Tue, Apr 19, 2011 at 6:22 AM, Boris Hollas 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 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 wrote: > On Sun, 2011-03-06 at 13:08 -0500, Alex Deucher wrote: >> On Fri, Mar 4, 2011 at 8:50 PM, Ben Hutchings 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 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 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 wrote: > Le 21/02/11 19:01, Cyril Brulebois a écrit : >> >> Hi Rémi, >> >> Rémi Letot (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#536098: xserver-xorg-video-radeon: deterministic X lockup with dri
On Mon, Feb 21, 2011 at 12:46 PM, Cyril Brulebois wrote: > Hi! > > Alex Deucher (08/07/2009): >> On Wed, Jul 8, 2009 at 8:22 AM, Jonathan Rafael >> Ghiglia 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#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 wrote: > Hi Alberto/Alex, > > Alex Deucher (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#613137: xserver-xorg-video-radeon: no video signal or kbd after manually launching X
On Mon, Feb 14, 2011 at 4:09 PM, GSR 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 wrote: > GSR 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
On Fri, Dec 17, 2010 at 5:21 PM, Marcos Marado wrote: > Hello again, > > 2010/12/17 Alex Deucher : >> 2010/12/16 Marcos Marado : >>> 2010/12/16 Michel Dänzer : >>>> 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 (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#607227: xserver-xorg-video-radeon: with kms, screen flickers, without kms xorg eats 100% CPU
2010/12/16 Marcos Marado : > Hi there, > > 2010/12/16 Michel Dänzer : >> 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 (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#585777: xserver-xorg-video-radeon: Radeon gamma bug still there
On Mon, Nov 22, 2010 at 9:14 PM, V. Gaibler 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 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 ) > 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 "" > (==) 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" > comp
Bug#570466: it's been a month, is this still a problem?
On Wed, Oct 13, 2010 at 3:28 PM, Rémi Letot 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 wrote: > On Mon, 2010-09-27 at 11:27 -0400, Alex Deucher wrote: >> On Mon, Sep 27, 2010 at 11:19 AM, Cyril Brulebois wrote: >> > Aaron Small (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 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#597358: xserver-xorg-video-radeon: Screen brightness flickers when KMS is enabled
On Mon, Sep 27, 2010 at 11:19 AM, Cyril Brulebois wrote: > Aaron Small (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#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 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 .
>
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
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
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#595767: xserver-xorg-video-radeon: Won't load hardware acceleration after system start
On Tue, Sep 7, 2010 at 6:48 AM, 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 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 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 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 11:55 AM, intrigeri 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 > | 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#583120: Hibernate broken when KMS enabled on Radeon Mobility M6 LY
On Fri, Aug 13, 2010 at 7:54 AM, intrigeri 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 > | 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#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 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 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 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 ) > 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 "" > (==) 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 > (
Bug#587999: further info
2010/7/6 Michel Dänzer : > 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 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 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 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 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 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, recon
Bug#574169: xserver-xorg-video-radeon: dims display after some days of uptime
On Wed, Mar 24, 2010 at 8:36 AM, Piotr Engelking 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 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] [] ? __alloc_pages_nodemask+0x476/0x4e0 > [ 372.981355] [] ? __get_free_pages+0xc/0x17 > [ 372.981363] [] ? __kmalloc+0x30/0x128 > [ 372.981404] [] ? radeon_cp_cmdbuf+0x111/0x121e [radeon] > [ 372.981416] [] ? do_page_fault+0x271/0x287 > [ 372.981423] [] ? do_page_fault+0x0/0x287 > [ 372.981435] [] ? error_code+0x73/0x78 > [ 372.981465] [] ? atom_rv515_force_tv_scaler+0xdb9/0x2ad2 > [radeon] > [ 372.981479] [] ? copy_from_user+0x104/0x10e > [ 372.981498] [] ? radeon_commit_ring+0x47/0x91 [radeon] > [ 372.981518] [] ? radeon_cp_texture+0x859/0x87f [radeon] > [ 372.981540] [] ? drm_ioctl+0x89/0x268 [drm] > [ 372.981554] [] ? drm_ioctl+0x1d2/0x268 [drm] > [ 372.981574] [] ? radeon_cp_cmdbuf+0x0/0x121e [radeon] > [ 372.981582] [] ? sched_clock+0x5/0x7 > [ 372.981592] [] ? sched_clock_local+0x15/0x11b > [ 372.981606] [] ? update_curr+0x106/0x1b3 > [ 372.981616] [] ? sched_slice+0x67/0x7f > [ 372.981623] [] ? hrtimer_forward+0x10c/0x124 > [ 372.981634] [] ? scheduler_tick+0xd3/0x1ec > [ 372.981644] [] ? vfs_ioctl+0x49/0x5f > [ 372.981651] [] ? do_vfs_ioctl+0x4aa/0x4e5 > [ 372.981661] [] ? __rcu_process_callbacks+0x6c/0x227 > [ 372.981669] [] ? rcu_process_callbacks+0x33/0x39 > [ 372.981678] [] ? __do_softirq+0x115/0x151 > [ 372.981685] [] ? sys_ioctl+0x41/0x58 > [ 372.981694] [] ? 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 > Memory Controller Hub (rev 04) > 00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 04) > 00:1e.0 PCI bridge: Inte
Bug#572311: No display output from Radeon RV610 on Alpha
On Sat, Mar 13, 2010 at 3:57 AM, Michael Cree wrote:
> On 13/03/10 06:57, Alex Deucher wrote:
>>
>> On Fri, Mar 12, 2010 at 4:57 AM, Michael Cree wrote:
>>>
>>> On 10/03/10 08:44, Alex Deucher wrote:
>>>>>>>>
>>>>>>>> On Sun, Mar 7, 2010 at 3:47 AM, Michael Cree
>>>>>>>> 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 2:50 PM, Bas Wijnen 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#573849: xserver-xorg-video-radeon: Be verbose about discarding modes
On Sun, Mar 14, 2010 at 2:32 PM, Bas Wijnen 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 7:50 AM, Bas Wijnen 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 "1600x1200"x0.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#572311: No display output from Radeon RV610 on Alpha
On Fri, Mar 12, 2010 at 4:57 AM, Michael Cree wrote:
> On 10/03/10 08:44, Alex Deucher wrote:
>>>>>>
>>>>>> On Sun, Mar 7, 2010 at 3:47 AM, Michael Cree
>>>>>> 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 wrote: > On 10/03/10 05:17, Matt Turner wrote: >> >> On Mon, Mar 8, 2010 at 6:30 PM, Michael Cree wrote: >>> >>> On 9/03/2010, at 5:41 AM, Alex Deucher wrote: >>>> >>>> On Sun, Mar 7, 2010 at 3:47 AM, Michael Cree 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 wrote: > On 07/03/10 03:34, Alex Deucher wrote: >> >> On Fri, Mar 5, 2010 at 8:10 PM, Michael Cree 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-devel&m=126611019424637&w=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 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 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-devel&m=126611019424637&w=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 wrote: > Alex Deucher 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 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 "" > (**) | |-->Device "Onboard Radeon" > (==) No monitor specified for screen "Default Screen". >
Bug#565313: dimmed screen with 16-bit depth using radeon driver
On Sat, Jan 30, 2010 at 10:04 PM, Alexander Sosedkin 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 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 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 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 Stahl 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 Goglin 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#541235: xserver-xorg-video-ati: New unexpected lock-ups
On Fri, Aug 21, 2009 at 10:40 AM, Stefano wrote: > Hello, > > I have no lock-ups with DRI disabled, and since I have to work now and > need stability, I won't "play" with DRI for a while. > > Also, I forgot to mention that I had those unexpected lock-ups when I > was using only my laptop monitor. > > Can you tell me how can I activate the radeon KMS? Or is it still not > implemented in the current debian package? I'm not sure there are any debian packages available, so you probably have to build from source. Easiest distro route right now for KMS is Fedora 11. 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 Fri, Aug 21, 2009 at 10:44 AM, Dimitri Chausson wrote: > Hi, > > Two new things I noticed: > > - switching between text console and X doesn't clear the problem anymore (my > system was updated a few times in between). So I do need the > "DisplayPriority" "BIOS" option set. > > - now stopping and starting gdm make the kernel log lines like the following > one: > Xorg:5365 freeing invalid memtype - > the memory area is from d0102000-d0112000 to d02f2000-d0302000 > Did installing the firmware get you up and running? -- 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 : > 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
