Bug#748463: libdrm2: [drm] Failed to open DRM device for pci:0000:01:00.0: No such file or directory
On 18/05/14 22:07, Omega Weapon wrote: On 17/05/14 22:35, Omega Weapon wrote: After many hours I have finally been able to break into X. The problem so far is an attempt to open /dev/dri/card1, which doesnt exist - /dev/dri/card0 is sitting there as normal. So I assume the issue is in xf86drm.c:drmOpenByBusid somehow breaking when trying card0, and then moving to card1. I'll look further into this tomorrow. So far I have demonstrated drmSetInterfaceVersion failing in drmOpenByBusId due to drmIoctl failing with EACCES - so looks like someones screwed up the permissions with /dev/dri/card0. Courtesy of LordVan on #radeon, there is a discrepancy with non-standard ACL (ls -al indicates non-standard ACL stuff with a + at the end): === # getfacl /dev/dri/card0 getfacl: Removing leading '/' from absolute path names # file: dev/dri/card0 # owner: root # group: video user::rw- group::rw- mask::rw- other::--- === On my working laptop, there is an extra 'user:omega:rw-' entry (that is my username), however I'd like to think the general user line does this. I added these permissions in with setfacl, but X was still broken. I'm currently reading into kernel documentation to understand the DRM_IOCTL_SET_VERSION ioctl in an attempt to show exactly what thinks I don't have the access. I'd appreciate someone with a clue helping here, as it is taking a long time to build up some for myself. Michel Dänzer of radeon fame has solved it - radeontop held /dev/dri/card0 open, and from what I understand only one thing can open this at a time. So basically radeontop held X hostage for 3 days. For anyone facing a similar problem, here is the check to see what is using the dri device and my actual example: = # sudo lsof /dev/dri/card0 COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME radeontop 4300 root5u CHR 226,0 0t0 10510 /dev/dri/card0 Xorg 6086 root 10u CHR 226,0 0t0 10510 /dev/dri/card0 = As soon as I killed radeontop and sudo service lightdm start, I could get back at my desktop. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5379fbe4.7050...@gmail.com
Bug#748463: libdrm2: [drm] Failed to open DRM device for pci:0000:01:00.0: No such file or directory
On 17/05/14 22:35, Omega Weapon wrote: After many hours I have finally been able to break into X. The problem so far is an attempt to open /dev/dri/card1, which doesnt exist - /dev/dri/card0 is sitting there as normal. So I assume the issue is in xf86drm.c:drmOpenByBusid somehow breaking when trying card0, and then moving to card1. I'll look further into this tomorrow. So far I have demonstrated drmSetInterfaceVersion failing in drmOpenByBusId due to drmIoctl failing with EACCES - so looks like someones screwed up the permissions with /dev/dri/card0. Courtesy of LordVan on #radeon, there is a discrepancy with non-standard ACL (ls -al indicates non-standard ACL stuff with a + at the end): === # getfacl /dev/dri/card0 getfacl: Removing leading '/' from absolute path names # file: dev/dri/card0 # owner: root # group: video user::rw- group::rw- mask::rw- other::--- === On my working laptop, there is an extra 'user:omega:rw-' entry (that is my username), however I'd like to think the general user line does this. I added these permissions in with setfacl, but X was still broken. I'm currently reading into kernel documentation to understand the DRM_IOCTL_SET_VERSION ioctl in an attempt to show exactly what thinks I don't have the access. I'd appreciate someone with a clue helping here, as it is taking a long time to build up some for myself. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53792107.3080...@gmail.com
Bug#748463: libdrm2: [drm] Failed to open DRM device for pci:0000:01:00.0: No such file or directory
Package: libdrm2 Severity: important Dear Maintainer, I don't know where to place this bug other than it is todo with X, radeon and DRM - libdrm-radeon1 comes from this package. Flagged as important as this is a serious issue for me - it has practically taken my main machine down and caused me to cancel a meeting this weekend. On restarting the machine on 16.05.14 after the CPU cut out due to overheating, after a successful boot X failed to start. There were pending updates (the special var reboot file was present), and I usually only restart once a month for updates (so there would be 10-16d of uptime at that point). I have attached the full Xorg log, but the key bit: == [53.375] (++) using VT number 7 [53.395] (II) [KMS] Kernel modesetting enabled. [53.395] (II) RADEON(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [53.395] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [53.395] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [53.395] (==) RADEON(0): Default visual is TrueColor [53.395] (==) RADEON(0): RGB weight 888 [53.395] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [53.395] (--) RADEON(0): Chipset: ATI Radeon 4800 Series (ChipID = 0x9440) [53.457] (EE) RADEON(0): [drm] Failed to open DRM device for pci::01:00.0: No such file or directory [53.457] (EE) RADEON(0): Kernel modesetting setup failed [53.457] (II) UnloadModule: radeon == The graphics card does exist and does work - I get a working text console with it on all inputs, and an Ubuntu 13.10 live CD works fine - so this is a software issue (and it worked perfectly before the reboot). I can see that X and mesa have changed recently - I attempted messy downgrades of libdrm and mesa based off the snapshot.debian.org site, but wasn't able to change the problem, and I stopped as I wasn't satisfied with this blind piecemeal manual method. Is there a proper way of telling aptitude to downgrade to packages present at a certain date? I currently use the 3.13 kernel, but booting into 3.12 and 3.14 has made no difference. I use radeon.dpm=0 to boot as the kernel stalls otherwise with occassional root volume corruption (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619). I have also tried booting with radeon.runpm=0 as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1068866#c2 , but this has made no difference. I intend to read into how this stuff works and find out what is responsible for this unacceptable failure, but I'll be starting from scratch so will need help. Thanks -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash [52.371] X.Org X Server 1.15.1 Release Date: 2014-04-13 [52.372] X Protocol Version 11, Revision 0 [52.372] Build Operating System: Linux 3.13-1-amd64 x86_64 Debian [52.372] Current Operating System: Linux omega1 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 [52.372] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.13-1-amd64 root=UUID=bfeb0912-9199-488e-8022-6a0ec4df0b48 ro debug ignore_loglevel elevator=deadline rootdelay=9 radeon.dpm=0 block.events_dfl_poll_msecs=2000 [52.372] Build Date: 15 April 2014 06:58:36PM [52.372] xorg-server 2:1.15.1-1 (http://www.debian.org/support) [52.372] Current version of pixman: 0.32.4 [52.372] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [52.372] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [52.372] (==) Log file: /var/log/Xorg.0.log, Time: Sat May 17 12:53:22 2014 [52.400] (==) Using config file: /etc/X11/xorg.conf [52.400] (==) Using system config directory /usr/share/X11/xorg.conf.d [52.497] (==) No Layout section. Using the first Screen section. [52.497] (==) No screen section available. Using defaults. [52.497] (**) |--Screen Default Screen Section (0) [52.497] (**) | |--Monitor default monitor [52.707] (==) No device specified for screen Default Screen Section. Using the first device section listed. [52.720] (**) | |--Device radeonhd6450 [52.720] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [52.720] (==) Automatically adding devices [52.720] (==) Automatically enabling devices [52.720] (==) Automatically adding GPU
Bug#748463: libdrm2: [drm] Failed to open DRM device for pci:0000:01:00.0: No such file or directory
After many hours I have finally been able to break into X. The problem so far is an attempt to open /dev/dri/card1, which doesnt exist - /dev/dri/card0 is sitting there as normal. So I assume the issue is in xf86drm.c:drmOpenByBusid somehow breaking when trying card0, and then moving to card1. I'll look further into this tomorrow. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5377d60f.70...@gmail.com
Bug#724264: [xserver-xorg-video-radeon] X server crashes in multiple programs attempting to view a jpg file
Package: xserver-xorg-video-radeon Version: 1:7.2.0-1+b1 This crashes X for me immediately too - ironically Thunderbird automatically loaded the attachment when this email came in. --- System information. --- Architecture: amd64 Kernel: Linux 3.10-2-amd64 Debian Release: jessie/sid 990 testing security.debian.org 990 testing ftp.uk.debian.org 500 unstableignorantguru.github.com 500 unstableftp.uk.debian.org 500 stable www.getgnash.org 500 quodlibet-unstable www.student.tugraz.at 1 experimentalftp.uk.debian.org --- Package information. --- Depends (Version) | Installed ===-+-== libc6 (= 2.17) | libdrm-radeon1 (= 2.4.31) | libpciaccess0 | libudev1 (= 183) | xorg-video-abi-12 | xserver-xorg-core (= 2:1.12.3.901) | Package's Recommends field is empty. Suggests(Version) | Installed =-+-=== firmware-linux| -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52415b30.60...@gmail.com
