Into.the.Void.

This is post is a rant. So don’t complain, I warned you.

<rant>
On my laptop (Macbook 4,1) I run Debian testing/experimental which was running quite smoothly since I installed it apart from the couple few weeks.

The first problem I faced was java not running inside browsers. Firefox, Iceweasel, Opera, google-chrome…nothing. I spent at least 2 hours installing/uninstalling various java packages, moving plugins to new locations and I couldn’t get it to work. I was furiously googling about the issue until I hit the jackpot: squeeze : in case you have no network connection with java apps ……

Today I upgraded xserver-xorg-input-synaptics from 1.2.0-2 to 1.2.1-1. Even though it is a minor version bump a kind fairy also told me to reboot…I rebooted and my touchpad was not working properly, tapping was lost, I couldn’t use synclient because shared memory config (SHM) was not activated and so on and so on. My dynamic config using hal was there, /var/log/Xorg.0.log said that I was using the proper device and lshal showed correct settings for the device. I read /usr/share/doc/xserver-xorg-input-synaptics/NEWS.Debian.gz nothing new. After some googling another jackpot: Bug#564211: xserver-xorg-input-synaptics: Lost tapping after upgrading to 1.2.1-1. For some reason touchpad config has moved to udev from hal and the maintainers didn’t think it was important enough that needed to be documented someplace or put it in README.Debian…

The last issue I am having is with linux-image-2.6.32-trunk-686-bigmem not working correctly with KMS and failing with DRM.
[ 0.967942] [drm] set up 15M of stolen space
[ 0.968030] nommu_map_sg: overflow 13d800000+4096 of device mask ffffffff
[ 0.968085] [drm:drm_agp_bind_pages] *ERROR* Failed to bind AGP memory: -12
[ 0.968159] [drm:i915_driver_load] *ERROR* failed to init modeset
[ 0.973067] i915: probe of 0000:00:02.0 failed with error -28

linux-image-2.6.32-trunk-686 works fine with those though.
[ 0.973466] [drm] set up 15M of stolen space
[ 1.907642] [drm] TV-16: set mode NTSC 480i 0
[ 2.137173] [drm] LVDS-8: set mode 1280x800 1f
[ 2.193497] Console: switching to colour frame buffer device 160x50
[ 2.197435] fb0: inteldrmfb frame buffer device
[ 2.197436] registered panic notifier
[ 2.197442] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

Xorg is amazingly sluggish using linux-image-2.6.32-trunk-686-bigmem kernel. I search the debian bugs database and noone seems to have reported such an issue. But google came up with: [G35/KMS] DRM failure during boot (linux 2.6.31->2.6.32 regression). The issue looks solved so I will try and report it to Debian and see what comes out of it…
*Update* Bug Report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567352

If you dare to comment saying “that’s what you get for using experimental” I really hope and curse you to spend 3 hours today to try and figure out what has changed in a minor version upgrade of one of your installed packages.
Even worse, if you are on those guys that kept telling me “don’t use stable, testing is stable as a rock, never had a problem in years…” then I curse you to spend a whole day trying to reconfigure something with no documentation 😛
<rant></rant>

Filed by kargig at 18:18 under Linux
Tags: bigmem, debian, drm, hal, java, linux-image, rant, sun-java6, synaptics, udev, xorg, xserver-xorg-input-synaptics
12 Comments | 9,708 views

It’s been a while since ivman stopped working on my Gentoo box but I never had the time nor the willingness to take a look into it. It appears that ivman is incompatible with some newer versions of hal and dbus. The good thing is that there’s an alternative, it’s called halevt and as far as I’ve taken a look into it the configuration options look quite straightforward.
For Gentoo, there are ebuilds for halevt on Gentoo bugzilla, which install just fine.

In my point of view there’s an issue here for Gentoo. Latest ivman (sys-apps/ivman-0.6.14) compiles just fine against all of its dependencies, but then it does nothing at all when a deviced is plugged in. If the devices are present when ivman starts then it can detect and mount them, if you plug the devices after ivman is started, then ivman does nothing at all. I think ivman is broken since hal 0.5.9.X versions. Gentoo developers stll keep ivman in the stable tree though. I find no real logic to this decision. Ivman is buggy with current stable hal and dbus. I would prefer a de-stabilization of ivman or even a package mask for it. What’s the point in keeping a package (ivman) in the stable tree since it requires not the latest stable but an older version of another package (hal) ? IMHO, since they correctly decided to stabilize hal 0.5.11-r8, which subsequently rendered ivman useless, ivman should be wiped from the stable tree.
Some bugs on ivman reported on Gentoo Bugzilla: http://bugs.gentoo.org/buglist.cgi?quicksearch=ivman

I once used ivman with a couple of custom scripts to create/remove icons of automounted devices on my ROX desktop. I think I can make these scripts work again with halevt…I am in the process of rewriting them. More on that in the following days…

Filed by kargig at 01:06 under Gentoo,Linux
Tags: automount, bug, bugzilla, Gentoo, hal, halevt, ivman, Linux, rox
7 Comments | 11,322 views