- Arch-general - lists.archlinux.org

[arch-general] kernel26-2.6.32.2-1 -- Radeon module (EE) config/hal ... org.freedesktop.DBus.Error.AccessDenied
by David C. Rankin 24 Dec '09

24 Dec '09

Guys, Working between the radeon and radeonhd modules, I noticed a strange error as the last line in my Xorg.0.log today that caught me by surprise. It was a hal/DBus error that I haven't seen before. Strange, what is a hal/dbus error doing in my Xorg log? The Radeon driver seems to be working OK, but I would like to find out what is going wrong and how I can fix the system so I don't get this error anymore. The error is: (II) RADEON(0): Setting screen physical size to 381 x 238 (EE) config/hal: couldn't find input device: org.freedesktop.DBus.Error.AccessDenied (Rejected send message, 1 matched rules; type="method_call", sender=":1.11" (uid=0 pid=16410 comm="/usr/bin/X) interface="org.freedesktop.Hal.Manager" member="FindDeviceByCapability" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=4062 comm="/usr/sbin/hald))) The box is my Toshiba 205d x86_64 laptop w/Radeon RS690M. The full log is here: http://www.3111skyline.com/download/linux/radeonhd/log/Xorg.0.22095221.log Anybody know what to do to figure out what is going on here? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 2

[arch-general] MAYDAY - drm/mesa/libgl/radeon updates - laptop stuck in 1152x864 - kdm locks on logout!
by David C. Rankin 24 Dec '09

24 Dec '09

Guys, I got bit bad tonight by the updates tonight. X starts but is stuck at 1152x864, if I log out, X freezes. Looks like bad libdrm and lib32-libdrm packages. Specifically, I upgraded: [2009-12-23 00:30] starting full system upgrade [2009-12-23 00:31] upgraded libdrm (2.4.17-1 -> 2.4.17-2) [2009-12-23 00:31] upgraded libgl (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded ati-dri (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded lib32-libdrm (2.4.16-1 -> 2.4.17-2) [2009-12-23 00:31] upgraded lib32-libgl (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded lib32-mesa (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded mesa (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded system-config-printer-common (1.1.13-1 -> 1.1.15-1) [2009-12-23 00:31] upgraded system-config-printer-gnome (1.1.13-1 -> 1.1.15-1) Next logout, the machine changed from 1440x900 to 1152x864 (the initial frame buffer resolution). Currently I am not using KMS with the radeon driver due to the current driver/initrd issues. I tried using a minimal xorg.conf setting the preferred resolution to 1440x900 (like I have done before to switch between the radeon/radeonhd drivers). X crashed immediately. Yes I had screens defined. X always started just fine with this xorg before. This is a short log: (this is the complete Xorg.0.log) X.Org X Server 1.7.3.901 (1.7.4 RC 1) Release Date: 2009-12-11 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-ARCH x86_64 Current Operating System: Linux alchemy 2.6.32-ARCH #1 SMP PREEMPT Sun Dec 20 10:01:30 CET 2009 x86_64 Kernel command line: root=/dev/disk/by-uuid/b004715c-1666-458a-b827-2bbb1d4a735e ro Build Date: 12 December 2009 08:39:02PM <snipped the definitions> Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor OK, so I had 2 choices, either try KMS with the nonworking drm or downgrade. I decided to downgrade. So I tried to downgrade with: pacman -U /var/cache/pacman/pkg/libdrm-2.4.17-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/libgl-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/ati-dri-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-libdrm-2.4.16-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-libgl-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-mesa-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/mesa-7.6.1-1-x86_64.pkg.tar.gz Which failed dependencies with mesa/libmesa requiring libdrm/lib32-libdrm > or = 2.4.17-2. HUH?? Deps whacked somewhere, I just upgraded from 2.4.17-1 and it was working fine... So I just eliminated the libdrm/lib32-libdrm packages and downgraded leaving drm the way mesa/libmesa wanted it. (Note the different downgrade times for libdrm below) X was still stuck in 1152x864, this caused me to suspect libdrm was the problem. So I went ahead and downgraded libdrm/lib32-drm with pacman -U --nodeps and then rebooted --> BING0 right back to 1440x900. Some notes on the log for the downgrade. The downgrade log looks weird to me. Maybe that's the way it should look, but I would expect correct version numbers: [2009-12-23 02:00] upgraded libgl (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded ati-dri (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded lib32-libgl (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded lib32-mesa (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded mesa (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:04] upgraded libdrm (2.4.17-2 -> 2.4.17-1) [2009-12-23 02:04] upgraded lib32-libdrm (2.4.17-2 -> 2.4.16-1) I may have missed some changelog that says change your config to XYZ for these packages, but honestly it just looks like this set of updates isn't quite done cooking yet. Let me know if you need for info, etc. I'm glad to provide logs, etc. I'll also go ahead and open a ticket if you think it is necessary. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 5

[arch-general] Xorg changes / DRM modules
by Andreas Radke 23 Dec '09

23 Dec '09

I've updated the git packages for nouveau and ati ddx driver packages in testing. I also updated the nouveau-drm package. This required to add the new nouveau-firmware package. It will be also needed to use kernel nouveau-drm module that will be introduced with kernel 2.6.33. I will keep updating the separate nouveua-drm module for a while to get features and fixes faster than in Linus tree. The firmware will probably also result in loading issues in early kms mode. We might think about recommending late mode for now. libdrm has been updated to 2.4.17 - this is breaking all radeon 3d stuff and will require changes in MESA when I understand the upstream devs right. Mesa7.7 is expected in a few days anyways and should make Radeon 3d stuff working again after a few late commits (7.7rc4 doesn't build with new libdrm). Other drivers should still work. Please test them. Radeon kms is still buggy like hell and unusable for my RC410 [Radeon Xpress 200M] card. It makes X and the whole system freeze instantly when moving windows around or when I try to start 3d apps. Sometimes even at Xorg start at all. This has been introduced with 2.6.32 kernels. Upstream recommends to try the various drm trees: http://article.gmane.org/gmane.comp.video.dri.devel/40626 Any opinions from other ati users what branch is the most stable and useful these days? I'm thinking about adding a radeon-drm kernel module package to solve the tons of speed and stability issues. As already written on the closed devel list, I'd like to get help for these packages from other devs and community members. Whoever is well informed in Xorg/kernel drm development and wants to help to stabilize our drivers please contact me. -Andy

5 5

[arch-general] Where'd the media:/ kioslave go in KDE4?
by David Rosenstrauch 23 Dec '09

23 Dec '09

Anyone know where the "media:/" kioslave has gone? When I enter that into konqueror it tells me "Protocol not supported media". For that matter, "system:/" and a few others seem to be missing as well. Am I missing some packages? Or did these go the way of the dodo in KDE4? Thanks, DR

1 0

[arch-general] [pkgstats] Patch to allow pkgstats to submit info through a proxy (if this is setted on http_proxy)
by Angel Velásquez 23 Dec '09

23 Dec '09

Hi, I've been trying to submit my stats to the statistics page [1], then I realized that I wasn't submitting anything (I had pkgstats running on a cron). Then I decided to find the reason and it's simply I am behing a noisy and non-transparent proxy (ISA Server which is even worst). So, I decided to do a little patch to pkgstats, I've tested and now it's working .. (I am checking if the http_proxy env var is empty and else I am setting a variable called prox which have the value of the proxy). Just that ;), patch attached [1] https://www.archlinux.de/?page=PackageStatistics -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com

3 6

Re: [arch-general] [arch-dev-public] Xorg changes / DRM modules
by Heiko Baums 23 Dec '09

23 Dec '09

Writing again to arch-general because of write permissions. Am Wed, 23 Dec 2009 11:21:03 +0100 schrieb Andreas Radke <a.radke(a)arcor.de>: > The sad part is that we leave all people with modern Ati cards in the > dark until upstream declares their code as stable. This will make them > going back to software rasterizer and either force them to use the > closed source driver or use weird self made git packages from AUR. Doesn't matter. A stable running system is better than new features which don't work yet, lead to regular crashes and make a system unusable. Some people need a stable system for working and need to trust in the stable repos. > Because I'm also affected with my weird X200m card I'm still looking > for a good solution how to offer a good set of binary packages people > can use to try modern code. I could do this on my own like all other > people from AUR but we could also setup an additional unstable repo at > Gerolde. I could do this also in my public dir. I'd prefer to have > people using one set of codebase for reporting bugs upstream. What do > you think? Aren't there already git versions for these packages in AUR? If you want to provide binary packages for them you could just move them to community or extra. But keep the names e.g. mesa-git, libdrm-git etc. and add a provides and conflicts variable to the PKGBUILDs (e.g. provides=libdrm and conflicts=libdrm). And by default (e.g. with pacman -S xorg) the stable packages are installed and if someone wants to test the unstable packages he can simply install the git packages. You could also add a new group xorg-git. In this case there should also a conflicts variable be added to the PKGBUILDs of the stable packages (conflicts=libdrm-git). I think with this solution everyone could be happy, people who need a stable system and people who want to test the latest unstable versions. And it has the advantage that people can easily switch between the stable and the unstable packages depending on how those packages work. When the new features go into the stable upstream packages the git versions could simply be removed from the repos. Greetings, Heiko

1 0

[arch-general] A universal Operating System API - why don't we have it?
by RedShift 22 Dec '09

22 Dec '09

Hi all It dawned on my that lots of industries have standards and companies generally keep to them. For example slabs of aluminium have standard sizes, building materials have well defined specifications, or take electrical components: there's a huge list of standardized components. You can expect between 220 and 240 VAC from your wall socket, fuses have standard formats and ratings, 1 meter here is exactly the same as 1 meter in another country, etc... Even CD's, which have been around for decades by now, have always been created using the same format (albeit extended somewhat, over time, but a normal CD pressed now should still play in a CD player that's 20 years old). It allows for a very competitive market where choices are made based on price, quality, availability, etc... Why doesn't the computer business have something similar? Sure processors are interchangeable in a limited way, we use standardized RAM, standard interfaces for accessing our peripherals, etc... But not when it comes to software. Why don't we have one universal API that works on every operating system? Yes there is libc, the language C is defined "in some way", but I'm talking about stuff that would make applications 100% portable. Things like enumerating all hardware devices, configuring a network interface, drawing a window, ejecting the CD-ROM drive, getting notified about new hardware plugged in, etc... It's different on every operating system. You cannot write a driver for Linux and expect it to work on FreeBSD. You cannot write an application for windows and expect it to work on Linux. When you buy a piece of hardware you usually hope for the best that it'll work out-of-the-box including all "extra" features. So why is that? Why hasn't someone stepped up and even try and create a universal operating system API? Is it because the computer business is still a "child" in some way, compared to other industries? Just a thought. Glenn

15 19

[arch-general] Kernel 2.6.32
by Frank Hale 22 Dec '09

22 Dec '09

I was using the testing kernel 2.6.32 without an issue but then when the kernel went to core my system would no longer boot. It would start to boot half way then just go dead. I don't have any error messages to post because the screen went blank. Grub was working fine as far as I can tell. I had to use the Arch live CD to revert kernels back to an earlier version. Has anyone been having issues with the stable kernel 2.6.32? Like I said, 2.6.32 from testing worked fine. Thanks.

7 12

Re: [arch-general] [arch-dev-public] [signoff] nano 2.2.1-1
by Heiko Baums 21 Dec '09

21 Dec '09

Am Mon, 21 Dec 2009 23:09:05 +0100 schrieb Andreas Radke <a.radke(a)arcor.de>: > note: since 2.2.0 nano failed to open PKGBUILDs for me. after removing > old /etc/nanorc and replacing it with the new one it works again. I'm answering to arch-general because I can't write to arch-dev-public. This issue is with the file /usr/share/nano/arch.nanorc. I haven't looked at it but after disabling it nano works again. Greetings, Heiko

1 0

[arch-general] [signoff] kernel 2.6.32.2-1
by Tobias Powalowski 21 Dec '09

21 Dec '09

Hi guys, Upstream changes: http://kernelnewbies.org/LinuxChanges Arch Linux bugfixes/feature requests: http://bugs.archlinux.org/task/16855 # added CONFIG_PM_DEBUG http://bugs.archlinux.org/task/17106 # added CONFIG_MMIOTRACE Arch Linux changes: - splitted kernel-headers to extra package If you want to build external modules please install: pacman -S kernel26-headers Please change your PKGBUILDS to makedepend on this package. - added xen support to 64bit kernel - changed intel kms enabled by default - changed to new firewire subsystem: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2