Picture of Jürgen Kreileder

Archive for the ‘Linux’ Category

Lockups with 2.6.12-rc-mm on PPC64

After many cycles of compiling and testing ppc64 kernels, I finally found out what causes 2.6.12-rc-mm kernels to lock up my PowerMac G5 regularly: It’s the recent changes in kernel/timer.c.
When I exclude the timer-* patches from the mm series everything works fine again.

I have not found a bug in these patches yet but I am pretty sure that it is no GCC bug.

PowerMac G5 ALSA Driver

Thanks to this patch from Benjamin Herrenschmidt, there finally is sound support for the PowerMac G5! It even works with ppc64 kernels.

Now if 2.6.12-rc kernels were just a tiny bit more stable on my G5…

PER_LINUX32 Fixes for Linux/ppc64

I’ve tried to rebuild the latest Debian packages of Mozilla and Firefox with my jsarena pointer arithmetic fix on ppc32/ppc64 today. Rebuilding worked fine with older versions but this time it failed because the makefiles identified my G5 as an i386 box! The makefiles use uname -m to determine the CPU type, there’s no code to handle ‘ppc64’ and the default is ‘x86’.

As my old work-around (providing a uname command that returns ‘ppc’) didn’t work anymore, this forced me to look at the root cause of the problem.

I’ve finally found two issues with the PER_LINUX32 personality:

  • uname(2) didn’t respect PER_LINUX32
  • Child processes didn’t inherit PER_LINUX32

This patch for 2.6.12-rc1-mm4 fixes both issues:

$ uname -m
ppc64
$ linux32 uname -m
ppc
$ linux32 sh -c "uname -m"
ppc

Without the patch all three commands return ‘ppc64’.

Logitech MX1000 Configuration

I’ve had to buy a new mouse, this time I got me a Logitech MX1000 (my first Logitech mouse ever). The Microsoft IntelliMouse Explorer I’ve used on my G5 got broken, it lost about two out of ten of clicks on the left button.

I’m not completely satisfied with the MX1000. It’s too heavy and a bit too small for my hands. The notable exception is the Forward button, it’s too far away from my thumb. I’ve had the last problem with the IntelliMouse Explorer too. I still have a few IntelliMouse Optical on other machines, I really like that mouse. Perfect Size, good wheel, easily reachable side buttons. The only drawback is the annoying big red light.

Anyhow, back to the MX1000. Only a few changes to my configuration for the IntelliMouse Explorer where needed to get it working. Here’s my new configuration:

  • /etc/X11/XF86Config-4 or /etc/X11/xorg.conf:
    Section "InputDevice"
     Identifier "MX1000"
     Driver     "mouse"
     Option     "CorePointer"
     Option     "Protocol"        "evdev"
     Option     "Dev Name"        "Logitech USB Receiver"
     Option     "Buttons"         "12"
     Option     "ZAxisMapping"    "11 12 10 9"
     Option     "Resolution"      "800"
     Option     "Emulate3Buttons" "false"
    EndSection
  • /etc/X11/Xmodmap:
    ! MX1000
    pointer = 1 2 3 8 9 10 11 12 6 7 4 5

    This gets the buttons in right order: Scrolling the wheel generates 4 and 5, tilting the wheel 6 and 7.

  • ~/.xbindkeysrc:
    (You have to install xbindkeys and xvkbd for this; I’m starting xbindkeys in ~/.gnomerc)
    # Backward and Forward buttons
    "xvkbd -text "\[Alt_L]\[Left]""
      m:0x10 + b:8
    "xvkbd -text "\[Alt_L]\[Right]""
      m:0x10 + b:9
    
    # "Cruise Control" disabled:
    #"xvkbd -text "\[Page_Up]""
    #  m:0x10 + b:11
    #"xvkbd -text "\[Page_Down]""
    #  m:0x10 + b:12
    
    # "Cruise Control" enabled:
    # Only use this if you have problems with Mozilla
    #"NoCommand"
    #  m:0x10 + b:11
    #"NoCommand"
    #  m:0x10 + b:12
    
    # Application-Switch button
    # A-Tab doesn't work
    # Use it as another Forward for now
    "xvkbd -text "\[Alt_L]\[Right]""
      m:0x10 + b:10

    Using the Application-Switch button for switching windows in GNOME doesn’t work because it would require holding down the Alt key while pressing Tab several times, xvkbd can’t do that. I’m using the button as another Forward now, it’s easier to reach than the real Forward button.
    Defining actions for the Cruise Control buttons only makes sense when Cruise Control is disabled (you can disable it with the Logitech Mouse Applet). If it is disabled, the buttons generate 11 and 12. When it is enabled, they generate a single button 11 or 12 event and then a series of button 4 or 5 events just like scrolling the wheel does.
    I have no idea why the mouse generates 11 or 12 before starting normal scrolling in Cruise Control mode. I’m mapping 11 and 12 to “NoCommand”, this eliminates the ButtonPress but not the ButtonRelease event. This seems to eliminate the negative effects of the extra button events in Mozilla. (Mozilla interprets the 11 and 12 events as normal left clicks, Firefox doesn’t have this issue. So if you’re using Firefox or if you don’t see the left-click problem with your Mozilla build, then don’t bind 11 and 12 to anything.)

  • At this point the Backward and Forward buttons should work in GNOME, KDE, and -based browsers. Horizontal scrolling should work in GNOME and KDE.
    Mozilla-based browser like need two additional changes to get horizontal scrolling working with the tilt wheel: Open about:config and set
    mousewheel.horizscroll.withnokey.action = 0
    mousewheel.horizscroll.withnokey.sysnumlines = true

April 5th, 2005: Update: Don’t bind 11/12 to anything in Cruise Control mode by default (only needed if there are problems with Mozilla). Fixed the "Cruise Control" comments in ~/.xbindkeysrc.

January 15th, 2006: Xorg 6.9 and later come with a different evdev driver. I’ve made an updated version of this guide now.

New Blackdown Security Advisory

Jouko Pynnönen has discovered an argument injection vulnerability in Java Web Start. I’ve just created a new Blackdown security advisory about this problem. Note that our current releases are not affected.