Created attachment 442512 [details] Xorg.0.log (looks like this is for 2.6.33) Description of problem: Fedora 13 was running fine on this Lenovo G555 laptop with ATI Radeon HD 4200 video until today's kernel update to 2.6.34.6-47. Now after the GRUB screen the video is extremely blurry and "noisy," and unreadable. Version-Release number of selected component (if applicable): Linux kernel 2.6.34.6-47.fc13.x86_64 How reproducible: boot into Linux kernel 2.6.34.6-47.fc13.x86_64 Steps to Reproduce: 1. 2. 3. Actual results: Video is blurry, "noisy" Expected results: Video is good Additional info: The system runs fine on the 2.6.33.8 kernel
Created attachment 442515 [details] Xorg.0.log for kernel 2.6.34 Passing nomodeset or radeon.modeset=0 to the boot line in grub has no effect
Created attachment 442523 [details] dmesg under kernel 2.6.34
I got the same thing on my desktop. No problem under 2.33. On reboot after update video wacked out like an old tv losing it's vertical & horizontal sync. I have a Radeon 3650 and I was able to boot using the nomodeset boot option. However when I logged into my desktop and started Firefox I got a warning that a kernel package had crashed. I was unable to run the report and now no longer able to start abrt tool as I get the following message: "Error while loading the dumplist. org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." Also I just checked my log file and I'm getting: ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(0). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(1). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(2). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(3). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(4). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(5). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(6). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(7). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(8). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(9). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(10). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(11). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(12). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(13). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(14). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(15). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(0). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(1). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(2). Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! Sep 1 22:14:17 ncc1701 kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(3). and that's just a small sample. I think I may go back to the older kernel for now.
I was able to retrieve part of the backtrace report created by abrt: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x24c/0x2ea [radeon]() Hardware name: GA-MA790FX-DS5 GPU lockup (waiting for 0x00000003 last fence id 0x00000001) Modules linked in: autofs4 it87 hwmon_vid sunrpc cpufreq_ondemand powernow_k8 freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 sha256_generic cbc kvm_amd kvm uinput or51132 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core tuner_simple tuner_types tda9887 tda8290 snd_hda_codec_atihdmi snd_hda_codec_realtek tuner snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device joydev snd_pcm cx8802 cx8800 cx88xx v4l2_common ir_common videodev v4l1_compat v4l2_compat_ioctl32 tveeprom ir_core btcx_risc videobuf_dma_sg videobuf_core snd_timer microcode wmi i2c_piix4 serio_raw snd r8169 mii k8temp edac_core edac_mce_amd soundcore snd_page_alloc aes_x86_64 aes_generic xts gf128mul dm_crypt firewire_ohci pata_acpi ata_generic firewire_core crc_itu_t pata_atiixp pata_jmicron radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] Pid: 2395, comm: Xorg Not tainted 2.6.34.6-47.fc13.x86_64 #1 Call Trace: [<ffffffff8104d12f>] warn_slowpath_common+0x7c/0x94 [<ffffffff8104d19e>] warn_slowpath_fmt+0x41/0x43 [<ffffffffa009ac03>] radeon_fence_wait+0x24c/0x2ea [radeon] [<ffffffff81066133>] ? autoremove_wake_function+0x0/0x39 [<ffffffffa009b30a>] radeon_sync_obj_wait+0x11/0x13 [radeon] [<ffffffffa006185e>] ttm_bo_wait+0xc0/0x157 [ttm] [<ffffffffa00ac9c3>] radeon_bo_wait+0xad/0xce [radeon] [<ffffffffa00aca24>] radeon_gem_wait_idle_ioctl+0x40/0x76 [radeon] [<ffffffffa00195f2>] drm_ioctl+0x26c/0x36a [drm] [<ffffffffa00ac9e4>] ? radeon_gem_wait_idle_ioctl+0x0/0x76 [radeon] [<ffffffff811d53b7>] ? inode_has_perm+0x7a/0x90 [<ffffffff810123a1>] ? might_fault+0x21/0x23 [<ffffffff810124c5>] ? save_i387_xstate+0x122/0x1cb [<ffffffff8111a9eb>] vfs_ioctl+0x32/0xa6 [<ffffffff8111af5e>] do_vfs_ioctl+0x483/0x4c9 [<ffffffff8109a0cf>] ? audit_syscall_exit+0x130/0x14c [<ffffffff8111affa>] sys_ioctl+0x56/0x79 [<ffffffff81009f23>] ? int_check_syscall_exit_work+0x34/0x3d [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b Hope that helps. I have since rebooted again and it seems more stable now so I may just stay with this kernel.
I have the same problem, although appending nomodeset to the kernel boot parameters solve the problem. I lost kms but I don't have any video artefacts. My card: 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series
In an effort to get my system (Lenovo G555 with ATI Radeon HD 4200 graphics) working again, I installed the proprietary ATI driver: AMD's proprietary driver for ATI graphics cards xorg-x11-drv-catalyst-10.8.1.fc13 The installation of that package automatically added radeon.modeset=0 to the GRUB bootline for the 2.6.34 kernel, and when booting with the new driver the video looks perfect. I don't get the nice boot screen that I had before (which you lose when turning off KMS), but Fedora 13 does boot into GDM and then into the desktop with no blurry, wavy display.
Same issues as above running 2.6.34.6-49 x86_64 F13 on ATi Mobility Radeon HD 2300 DVI/VGA port.
Created attachment 446072 [details] xorg.conf for kernel 2.6.34 I didn't know I was running with an xorg.conf. This file was automatically generated by the system. This file shows that fglrx is the driver.
(In reply to comment #8) > Created attachment 446072 [details] > xorg.conf for kernel 2.6.34 > > I didn't know I was running with an xorg.conf. This file was automatically > generated by the system. > > This file shows that fglrx is the driver. The file was not generated by the system but by fglrx, so that Xorg doesn't use the automatically chosen driver (which would be ati). If you add just nomodeset=0 to the kernel command line and remove the fglrx driver, is the situation better as well? Thank you for filing the bug report
I can confirm that appendend nomodeset to the kernel boot parameters solve the problem. At least the image is "clean".
In my situation, with the "original" driver (before I added fglrx), radeon.modeset=0 or nomodeset in the boot line did not work. I can try those again with the ati driver just to confirm.
I removed the fglrx driver. This is what happened: -- An xorg.conf was created that called for the vesa driver -- using radeon.modeset=0 at the boot line yields good X video, but at 1024x768, not 1366x768, which I can't force by modifying xorg.conf. Changing "vesa" to "ati" in the xorg.conf doesn't work. Running w/o xorg.conf doesn't yield good video So for now I'm back to fglrx (which has good 1366x768 video with radeon.modeset=0 in the boot line, as added to Grub by the fglrx package).
I decided to return to the xorg-x11-drv-ati-6.13.0-1.fc13 (x86_64) driver. I removed the fglrx driver, deleted the xorg.conf it created, and reinstalled the open ati driver. Now video is perfect with the 2.6.33.8-149.fc13.x86_64 kernel, but with these kernels setting radeon.modeset=0 in the bootline still yields blurry, out of sync video: 2.6.34.6-54.fc13.x86_64 2.6.34.6-47.fc13.x86_64
I'd like to correct the last comment, now that I've gone through the three kernels on my Fedora 13 system. Works without adding radeon.modeset=0 2.6.33.8-149.fc13.x86_64 Works with adding radeon.modeset=0 2.6.34.6-47.fc13.x86_64 Doesn't work with or without radeon.modeset=0 2.6.34.6-54.fc13.x86_64
Now I'm back where I was with 2.6.33 only. I'm not sure why turning off KMS in the boot line is so intermittent in 2.6.34.6-47.
Mobility Radeon HD 2300. Periodic graphical noise, as if pixels are shifting horizontally back and forth. Should I open a new bug? 2.6.34.7-61.fc13.x86_64 kernel version.
appending radeon.modeset=0 to kernel parameters causes distortion of the login screen and soft reboot of the system when I attempt to add a panel under KDE.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.