dri-devel April 2013

dri-devel@lists.freedesktop.org

142 participants
765 discussions

[Bug 53391] New: nouveau: wrong display output order
by bugzilla-daemon＠bugzilla.kernel.org 08 Dec '21

08 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=53391 Summary: nouveau: wrong display output order Product: Drivers Version: 2.5 Kernel Version: 3.8-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: stijn+bugs(a)linux-ipv6.be Regression: No My graphics card is a Gainward GTX480 (http://www.gainward.com/main/vgapro.php?id=238). It has 2 DVI outputs, and 1 mini HDMI output. The DVI outputs are numbered on the card, with DVI 1 being the closest to the PCIe slot, then DVI 2, and finally the mini HDMI. My primary (left) monitor, is connected to DVI 1, my secondary (right) monitor to DVI 2. When I boot the computer, the BIOS initializes and uses the monitor on DVI 1. Grub is displayed on the primary monitor, and the kernel initially outputs to the primary monitor as well. However, as soon as the nouveau module is loaded, the primary monitor goes to standby and the kernel now uses the secondary monitor (on DVI 2) as primary. When X starts (no Xorg.conf file), it is also displayed on the secondary monitor. When using either efifb, vesafb or uvesafb, the monitor on DVI 1 is always the primary monitor. X with nvidia.ko also uses DVI 1 as the primary display. Finally, when booting Windows, the startup screen is also displayed on the monitor connected to DVI 1. Here comes the weird part: when I am in X, and run xrandr, it does show 3 connected devices: DVI-I-1, DVI-I-2, and HDMI-1, with DVI-I-2 being the only active one. So it seems that in X, the output order is correct, but with nouveaufb the DVI connectors are swapped. I will attach the output of dmesg here. If anything else is needed, please let me know and I'll be happy to add it. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 13

[Bug 51381] New: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
by bugzilla-daemon＠bugzilla.kernel.org 11 May '21

11 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=51381 Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo Product: Drivers Version: 2.5 Kernel Version: Linux version 3.6.9-1-ARCH (tobias@T-POWA-LX) (gcc version 4.7.2 (GCC) ) #1 SMP PREEMPT Tue Dec 4 08:04:10 CET 2012 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: a(a)anrd.net Regression: Yes Created an attachment (id=88591) --> (https://bugzilla.kernel.org/attachment.cgi?id=88591) journald log After updating from 3.6.6 to 3.6.9 my laptop with Intel graphics and ATI HD 5650 will not resume from suspend. I use vgaswitcheroo to disable the ATI card at boot. On resume the computer almost hangs (I can press power button and wait 5 minutes for a proper shutdown, but no other interaction is possible). It logs a lot of messages saying: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D098 (len 72, WS 0, PS 0) @ 0xD0C7 Steps to reproduce: echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch [suspend and resume] Actual results: Almost freeze. Expected results: Resume and work as normal. Log is attached, but if you need anything else just ask. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 62

[Bug 32556] New: screen flickers all the time with desktop image appearing only briefly
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=32556 Summary: screen flickers all the time with desktop image appearing only briefly Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: 3ntr0p13(a)gmail.com Created an attachment (id=41344) --> (https://bugs.freedesktop.org/attachment.cgi?id=41344) dmesg Machine is the same as in bug report 28331 although with different software components: Acer Aspire L5100 with an AMD Athlon 64 X2 Dual Core Processor 4000+, this time running a 64 bits debian squeeze. The machine is a small factor desktop machine designed around laptop components, so the graphic card is an integrated radeon x1200. When running a linux vanilla kernel 2.6.37-rc6, the screen flickers all the time making the machine unusable, while with debian kernel 2.6.32-5 such "flick to black" event occur from time to time, making it annoying but usable. While booting with radeon.modeset=0 the problem doesn't exhibits itself The following packages version from debian squeeze are installed: xserver-xorg 1:7.5+8 xserver-xorg-core 2:1.7.7-10 xserver-xorg-video-radeon 1:6.13.1-2+squeeze1 Please find attached Xorg.0.log, dmesg, register dumps for ums and kms for that machine (when booted on 2.6.37-rc6). Regards, Gildas -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 38

[Bug 32422] New: Large images displayed in Firefox appear corrupted
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=32422 Summary: Large images displayed in Firefox appear corrupted Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: da_fox(a)mad.scientist.com Created an attachment (id=41150) --> (https://bugs.freedesktop.org/attachment.cgi?id=41150) Picture describing a thousand words. "A picture says more than a thousand words" (aka see attachment) This is what happens when I try to view the XKCD "Online Communities 2" map (http://xkcd.com/802_large/) or other large images in firefox. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 21

[Bug 62671] New: KDE thinks the monitor is reconnected each time it resumes
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=62671 Priority: medium Bug ID: 62671 Assignee: dri-devel(a)lists.freedesktop.org Summary: KDE thinks the monitor is reconnected each time it resumes Severity: normal Classification: Unclassified OS: Linux (All) Reporter: chealer(a)gmail.com Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI I experienced a regression after upgrading Linux from Debian's 3.2.35-2 to its 3.2.39-2. As Ben Hutchings explained to me, that is because some Linux 3.3/3.4 graphics changes were backported in Debian's 3.2.39. And indeed, if I try 3.4.4 or 3.8.3, the regression remains. I have only experienced the problem on KDE, but I didn't try other environments. My laptop has a Radeon HD 5650 card connected to an LCD screen via HDMI. When I leave the laptop idle and come back after a while, the screen resumes. What changed is that I now get 2 KDE dialogs telling me: A monitor output has been disconnected. Do you wish to run a configuration tool to adjust the monitor setup? immediately followed by A monitor output has been connected. Do you wish to run a configuration tool to adjust the monitor setup? (The latter shows on top) Obviously, this is incorrect. I simply press Escape twice and the problem disappears until the next time I leave the PC. This is just an annoyance. I ran tail --follow on .xsession-errors to debug and found as only clue the message "main input error: ES_OUT_RESET_PCR called" logged twice. For example, after a monitor resume, the following had been logged: [0x85fc680] main input error: ES_OUT_RESET_PCR called [0xf1b0a9b8] main input error: ES_OUT_RESET_PCR called I noticed that this error is logged every time the system detects a monitor (dis)connection, real or spurious (On my good Linux version, a resume doesn't trigger that error). Oddly enough, I searched the web quite a bit, asked #debian-kde and #kde and found no one with the same problem. The ES_OUT_RESET_PCR error is common, but in very different contexts. This does not happen when using the vesa driver, nor when modeset is disabled, nor when I plug the screen via VGA (the laptop has no DVI plug to test). There are no hints in system logs. The KDE prompts above are the standard prompts shown when a (dis)connection is detected. Debian testing's KDE version is not the latest (4.8.4). -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 62246] New: LVDS screen mode switching fails
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=62246 Priority: medium Bug ID: 62246 Assignee: dri-devel(a)lists.freedesktop.org Summary: LVDS screen mode switching fails Severity: major Classification: Unclassified OS: Linux (All) Reporter: felix-freedesktop(a)fefe.de Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI I have a HP Envy 14 laptop, which has switchable graphics between: 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Madison [Radeon HD 5000M Series] (rev ff) This used to work (I'm not using it very often, so I don't know which kernel version broke it), and I think it caused total kernel hang in 3.0 till 3.3 or so. Not it "works" in the sense that when a HDMI cable is connected, I get a picture on the connected monitor. But the primary display output, LVDS-2, stays black. Here's the relevant dmesg parts: agpgart-intel 0000:00:00.0: Intel HD Graphics Chipset agpgart-intel 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable agpgart-intel 0000:00:00.0: detected 32768K stolen memory agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xb0000000 [drm] Initialized drm 1.1.0 20060810 i915 0000:00:02.0: setting latency timer to 64 i915 0000:00:02.0: irq 40 for MSI/MSI-X [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem vgaarb: transferring owner from PCI:0000:00:02.0 to PCI:0000:01:00.0 ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared ACPI: Battery Slot [BAT0] (battery present) ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared ACPI: Battery Slot [BAT1] (battery absent) [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 fbcon: inteldrmfb (fb0) is primary device Console: switching to colour frame buffer device 200x56 i915 0000:00:02.0: fb0: inteldrmfb frame buffer device i915 0000:00:02.0: registered panic notifier [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness acpi device:01: registered as cooling_device5 ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS acpi device:0a: registered as cooling_device6 ACPI: Video Device [PEGP] (multi-head: yes rom: no post: no) input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/LNXVIDEO:01/input/input4 [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. VGA switcheroo: detected switching method \_SB_.PCI0.GFX0.ATPX handle radeon 0000:01:00.0: enabling device (0000 -> 0003) [drm] initializing kernel modesetting (REDWOOD 0x1002:0x68C1 0x103C:0x1436). [drm] register mmio base: 0xC4400000 [drm] register mmio size: 131072 vga_switcheroo: enabled ATPX version 1 ATOM BIOS: MADISON radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) radeon 0000:01:00.0: GTT: 512M 0x0000000040000000 - 0x000000005FFFFFFF mtrr: no more MTRRs available [drm] Detected VRAM RAM=1024M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 3980934 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 1024M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. radeon 0000:01:00.0: irq 45 for MSI/MSI-X radeon 0000:01:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] probing gen 2 caps for device 8086:45 = 1/0 [drm] Loading REDWOOD Microcode [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). radeon 0000:01:00.0: WB enabled radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880251324c00 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880251324c0c radeon 0000:01:00.0: enabling bus mastering [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 3 succeeded in 1 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] radeon atom DIG backlight initialized [drm] Radeon Display Connectors [drm] Connector 0: [drm] LVDS-2 [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c [drm] Encoders: [drm] LCD1: INTERNAL_UNIPHY [drm] Connector 1: [drm] DP-1 [drm] HPD2 [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY1 [drm] Connector 2: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY1 [drm] Internal thermal controller with fan control [drm] radeon: power management initialized [drm] fb mappable at 0xA0142000 [drm] vram apper at 0xA0000000 [drm] size 5787648 [drm] fb depth is 24 [drm] pitch is 6400 radeon 0000:01:00.0: fb1: radeondrmfb frame buffer device [drm] Initialized radeon 2.29.0 20080528 for 0000:01:00.0 on minor 1 When I start the intel framebuffer, the display is also black, but I found out that that is just the brightness set to 0, so I wrote a little too that writes to /sys/class/backlight/acpi_video0/brightness to set a sensible brightness. When the radeon screen stayed black, I assumed the same problem, so I changed my tool to also write to /sys/class/backlight/acpi_video1/brightness, but this does not help. To check whether this was related to VGA switcheroo interactions, I compiled a kernel with no Intel driver in it and insmod'ed the radeon module. This time the LVDS display stayed in text mode and "hung" in the sense that the text did not continue scrolling. I something is attacked on the HDMI output, that display gets a text console when I insmod radeon. When I start X, the LVDS screen still stays broken, but the console disappears from the HDMI screen, and the laptop appears to hang. My default setup within X is to have an xterm, so I moved my mouse into that xterm (without seeing any of it) and started a shell script that uses xrandr to set up the second display, but nothing happened. It felt as if the Intel driver still felt responsible for LVDS. Since I'm using X in non-radeon mode all the time, I have no Xorg.log left from my radeon testing. I can tell you though what was in it. No (EE) lines. I originally used X.org 1.12.3, then switched to 1.14 to see if that would make the problem disappear. I tried the latest release versions of libdrm and xf86-intel-radeon but when that did not work, I upgraded to the git versions of both. No improvement. I can try again tonight at home and produce an Xorg.0.log for you. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 59903] New: [RS880] Xorg.0.log: flip queue failed: Device or resource busy
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=59903 Priority: medium Bug ID: 59903 Assignee: dri-devel(a)lists.freedesktop.org Summary: [RS880] Xorg.0.log: flip queue failed: Device or resource busy Severity: normal Classification: Unclassified OS: All Reporter: michaell(a)gmx.org Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 73686 --> https://bugs.freedesktop.org/attachment.cgi?id=73686&action=edit dmesg /var/log/Xorg.0.log is full with: [ 1599.434] (WW) RADEON(0): flip queue failed: Device or resource busy [ 1599.434] (WW) RADEON(0): Page flip failed: Device or resource busy running up-to-date gentoo-system, with the following (unstable) packages linux-3.8.0-rc5 compiled a few minutes ago xorg-server-1.13.1 compiled a few minutes ago libdrm from git compiled a few minutes ago mesa from git compiled a few minutes ago xf86-video-ati from git compiled a few minutes ago 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880 [Radeon HD 4290] my system is working as an htpc and is running fine, no crashes or oops slim is login my user and starts xbmc automatic xbmc in fullscreen is the only graphical application the system is connected to my tv through hdmi if i switch with my remote through the xbmc-menu or watch a video the xorg-log is spam the whole time with page filp errors if i leave xbmc alone, so the log is spam every few seconds with page flip errors is this related to this bug? https://bugs.freedesktop.org/show_bug.cgi?id=58659 my system is working fine, no crashes or oops so far -- You are receiving this mail because: You are the assignee for the bug.

1 13

[Bug 59219] New: [radeon BUG] Sleeping function called from invalid context
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=59219 Priority: medium Bug ID: 59219 Assignee: dri-devel(a)lists.freedesktop.org Summary: [radeon BUG] Sleeping function called from invalid context Severity: minor Classification: Unclassified OS: Linux (All) Reporter: ebiggers3(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 72816 --> https://bugs.freedesktop.org/attachment.cgi?id=72816&action=edit dmesg output showing 2 instances of radeon BUG during resume I am running linux-3.8-rc3 on AMD64 with various debugging options enabled, including CONFIG_DEBUG_SLAB. When resuming the system from suspend-to-memory, I run into a warning and stacktrace regarding kmem_cache_alloc() being called from an invalid context in ttm_bo_move_accel_cleanup(). dmesg output attached. Marked as minor because suspend still works properly (at least the times I've tried it). Based on the source code and object file it appears that the memory allocation is actually the kzalloc() at the beginning of ttm_buffer_object_transfer(). Graphics card is: 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880M [Mobility Radeon HD 4200 Series] -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 58914] New: Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=58914 Priority: medium Bug ID: 58914 Assignee: dri-devel(a)lists.freedesktop.org Summary: Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: david.hagood(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 72358 --> https://bugs.freedesktop.org/attachment.cgi?id=72358&action=edit X Start up log messages The Radeon driver will not load with the Radeon kernel drivers in Linux 3.8.0 The following is an excerpt from the startup: [ 109.112] (II) Loading extension DRI2 [ 109.112] (II) LoadModule: "radeon" [ 109.112] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [ 109.112] (II) Module radeon: vendor="X.Org Foundation" [ 109.112] compiled for 1.12.3, module version = 7.0.99 [ 109.112] Module class: X.Org Video Driver [ 109.112] ABI class: X.Org Video Driver, version 12.0 [ 109.112] (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), (many cards snipped) [ 109.114] (--) using VT number 8 [ 109.119] (II) [KMS] Kernel modesetting enabled. [ 109.120] (II) RADEON(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 109.120] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 109.120] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 109.120] (==) RADEON(0): Default visual is TrueColor [ 109.120] (==) RADEON(0): RGB weight 888 [ 109.120] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 109.120] (--) RADEON(0): Chipset: "ATI Radeon HD 4350" (ChipID = 0x954f) [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: Searching for BusID pci:0000:04:00.0 [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: drmOpenMinor returns 9 [ 109.120] drmOpenByBusid: Searching for BusID pci:0000:04:00.0 [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: drmOpenMinor returns 9 [ 109.120] drmOpenByBusid: Interface 1.4 failed, trying 1.1 [ 109.120] drmOpenByBusid: drmGetBusid reports That last line is not a copy/paste issue - it literally is "[ 109.120] drmOpenByBusid: drmGetBusid reports " (as in, there is no bus ID given) Then the X Radeon driver looks for any other DRI node, fails, and dies. [ 109.120] drmOpenDevice: node name is /dev/dri/card1 [ 109.125] drmOpenByBusid: drmOpenMinor returns -1 (snip many other searches) [ 109.170] drmOpenDevice: node name is /dev/dri/card14 [ 109.174] drmOpenByBusid: drmOpenMinor returns -1 [ 109.174] drmOpenDevice: node name is /dev/dri/card15 [ 109.178] drmOpenByBusid: drmOpenMinor returns -1 [ 109.178] drmOpenDevice: node name is /dev/dri/card0 [ 109.178] drmOpenDevice: open result is 9, (OK) [ 109.178] drmOpenDevice: node name is /dev/dri/card0 [ 109.178] drmOpenDevice: open result is 9, (OK) [ 109.178] drmGetBusid returned '' [ 109.178] (EE) RADEON(0): [drm] failed to set drm interface version. [ 109.178] (EE) RADEON(0): Kernel modesetting setup failed [ 109.178] (II) UnloadModule: "radeon" [ 109.178] (EE) Screen(s) found, but none have a usable configuration. I have tried the following: 1) adding the following parameters in /etc/modprobe.d/radeon.conf options radeon modeset=1 dynclks=1 gartsize=256 audio=1 pcie_gen2=-1 msi=1 2) Adding the following to /etc/initramfs-tools/modules radeon modeset=1 dynclks=1 gartsize=256 audio=1 pcie_gen2=-1 msi=1 and rebuilding the ramdisk. The kernel has the following configuration with respect to the Radeon drivers: CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y # CONFIG_FB_RADEON is not set -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 58747] New: [RS780] Backtrace if firmware is not available on kernel-3.7
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=58747 Priority: medium Bug ID: 58747 Assignee: dri-devel(a)lists.freedesktop.org Summary: [RS780] Backtrace if firmware is not available on kernel-3.7 Severity: normal Classification: Unclassified OS: All Reporter: ojab(a)ojab.ru Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 72109 --> https://bugs.freedesktop.org/attachment.cgi?id=72109&action=edit Related dmesg output After updating to kernel 3.7 I get backtrace if booting without firmware available (related dmesg part in the attached file). Also reproducible with kernel 3.7.1. -- You are receiving this mail because: You are the assignee for the bug.

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2013