Ask Klaus!


Klaus Knopper is the creator of Knoppix and co-founder of the LinuxTag expo. He currently works as a teacher, programmer, and consultant. If you have a configuration problem, or if you just want to learn more about how Linux works, send your questions to: klaus@linux-magazine.com.

System Crash

Question:

My system keeps crashing at moments that seem completely random. Someone suggested I do a "memory dump" to look for clues. Are there some tools I can use to analyze the memory contents? If so, what should I look for?

Answer:

Try running memtest86+ from a boot floppy first, http://www.memtest.org/. memtest86+ will do a thorough check of your computer's RAM. Sometimes this check finds bad RAM. Sometimes, however, memory errors are caused by bad refresh timings set in the BIOS. These kinds of problems may only occur under heavy system load that are not simulated with tools like memtest86+.

The following test recipe worked well for me in one case where everything else just did not find anything wrong. There should be enough space in /tmp/ in order to do the test:

  1. Start with something like the following:
    dd if=/dev/urandom of=/tmp/test1 bs=1000k count=size_of_your_memory_in_MB
  1. As root (required for -f option), do some (a dozen): Each ping -f localhost will add a system load of about 1-2.
    ping -f localhost >/dev/null 2>&1 &
    ping -f localhost >/dev/null 2>&1 &
    ping -f localhost >/dev/null 2>&1 &
    ...
  1. Then perform the following test to investigate the problem:
    while true; do
    cp /tmp/test1 /tmp/test2;
    md5sum /tmp/test1
    /tmp/test2; done

In the case that the files differ (different md5 sums), there are either ramdomly changing bits in your computer's RAM memory (use a ramdisk in order to rule out a harddisk error), or some IO controller (harddisk, PCI bridge?) has gone crazy. In this case, I would let the vendor who sold it to you replace the board as a warranty case, because it is a terrible task to find out which type of RAM with which BIOS timing will work out on your own, and whatever you decide, this will probably not give you the "perfect" setting.

And no, it is not "a Linux-related problem" if the test I described clearly shows errors.

USB Mice

Question:

I really want to use a mouse with  my Linux portable computer. Unfortunately, the latest laptops don't come with PS2 connections.

www.sxc.hu

The obvious answer would be to use a USB mouse, however, in poking around on several Linux distributions, I found that Xorg doesn't seem to run properly with a USB (USB2.0) mouse. I noticed, however, that if I stick in the Knoppix CD to use my computer with Knoppix, there is no problem whatsoever with a USB mouse. The fact that Knoppix works with a USB mouse makes me think this mouse problem is not something about the hardware.

Unlike many contemporary distros, Knoppix still uses XFree and not Xorg.

What is the problem and how can I fix it? I'm running an HP NX6110; dmesg indicates a memory clash, leaving the mouse with a message that it has run out of available MTRR.

Ideally, I would like to get the laptop working under the latest version of Slackware, which uses the Xorg graphics system. The main application I intend to run uses the Postgresql database, and I'm sure I could get it to run under other Linux distributions if necessary.

Answer:

The question falls into several categories, so I'll split my answer.

Laptops without PS/2

I used to think that a laptop without a PS/2 connector was something probably no vendor would be able to sell. Well, it seems that this assumption of mine has just been proven wrong. So there really are computers that don't have a PS/2 connector? I should have guessed, since I remember the days when they started removing the floppy drives yet keeping a disfunctional floppy controller on the board for "compatibility reasons"...

No big deal, though. Linux, even with PS/2 support built in, will run fine without a PS/2 device.

Hardware Problem?

It could be a hardware problem if the kernel gets stuck when trying to access a non-existing PS/2 mouse or a PS/2 port with really broken interrupt routing (maybe ACPI or APIC is the reason). If this is the problem in your case, you could think about maybe adding something like:

acpi=off

or the opposite

acpi=force

and/or

noapic pnpbios=off

to the APPEND kernel options for lilo, grub or syslinux. This could save you from disfuncional interrupts. Also:

pci=irqmask=0x0e98

is reported to be helpful in case of PS/2 related interrupt problems.

XFree vs. Xorg Servers and PS/2 vs. USB mice

To the best of my knowledge, the XFree and Xorg servers are not only syntax-compatible from their configuration files in a wide range, but also share the same kind of hardware detection. Also, Knoppix 5 is already using Xorg (with almost the same configuration file that XFree had). Primarily this switch to Xorg is because virtually every distribution (including Debian) is switching to Xorg nowadays.

So, getting the USB mouse and Xorg to work correctly without a PS/2 mouse as a primary pointer device is more of a (mis-)configuration issue than a problem related to the issues of Xorg vs. XFree.

Have a look inside /etc/X11/xorg.conf. Whether you have several mice attached to your computer, only one mouse, or no mouse at all, make sure that the following entry exists in xorg.conf:

Section "ServerFlags"
Option "AllowMouseOpenFail" "true"
EndSection

This will allow your X Server to start, even when there is an error in the internal mouse setup procedure of XFree/Xorg.

Now, if it so happens that you have a completely uncooperative mouse, with the pointer just sitting in the middle of your screen and not responding to anything, you can still use the keyboard to simulate mouse movements. Press LeftControl-Shift-NumLock (on the numeric keypad) simultaneously. Usually, this causes a short beep. Then you should be able to move the mouse using the number keys on the numeric keypad (or the number key emulation using the extended function key on some laptops). In some cases, you need to hit the NumLock key TWICE to let this work. Note that this is an X Server feature, so it should not depend on the type of desktop you use.

Anyway, let's try to get the USB mouse working (with or without the additional PS/2 mouse).

Knoppix (sometimes) has two or more mice listed in the ServerLayout section of xorg.conf (see Listing 3).

Listing 3: Mouse entry in Knoppix
01 Section "ServerLayout"
02 ...
03 InputDevice    "USB Mouse"  "CorePointer"
04 InputDevice    "PS/2 Mouse" "CorePointer"
05 EndSection

An XFree/Xorg expert may point out that this approach is completely wrong, because there can only be ONE CorePointer.

Also, XFree/Xorg generates a big warning about the fact that there are TWO of these pointers present in the config file. Well, in spite of the warning message about extra pointers, this configuration has been working perfectly in Knoppix, exactly in this syntax, for years now, and X needs at least one working CorePointer in order for mouse operations to work. This option gives you a backup in case one fails in initialization; so yes, Xorg can have more than one CorePointer.

But in the case of a laptop that doesn't have a PS/2 connector, and just happends not to have an "internal" PS/2 touchpad or stick, you can remove or comment out the InputDevice "PS/2 Mouse" "CorePointer" line.

Listing 1 (see p57) is an example of a "PS/2 Mouse" entry:

The configuration in Listing 1 can even stay in xorg.conf if the InputDevice "PS/2 Mouse" "CorePointer" line has been removed from the ServerLayout section.

Listing 1: PS/2 Mouse in xorg.conf
01 Section "InputDevice"
02  Identifier "PS/2 Mouse"
03  Driver     "mouse"
04  Option     "Protocol" "auto"
05  Option     "ZAxisMapping" "4 5"
06  Option     "Device" "/dev/psaux"
07  Option     "Emulate3Buttons" "true"
08  Option     "Emulate3Timeout" "70"
09  Option     "SendCoreEvents"  "true"
10 EndSection

For a USB mouse, see the example in Listing 2 (p57).

Listing 2: USB mouse entry in xorg.conf
01 Section "InputDevice"
02  Identifier "USB Mouse"
03  Driver     "mouse"
04  Option     "Device"         "/dev/ input/mice"
05  Option     "SendCoreEvents" "true"
06  Option     "Protocol"       "IMPS/2"
07  Option     "ZAxisMapping"   "4 5"
08  Option     "Buttons"        "5"
09 EndSection

The configuration in Listing 2 should work for the majority of USB mice. If /dev/input/mice seems dead, you probably have no "evdev" compiled in the kernel or the "evdev" module is not loaded. For some kernels, the PS/2 mouse events are replicated in /dev/input/mice, together with the USB mouse events, so you actually really need ONLY the InputDevice "USB Mouse" "CorePointer" line in ServerLayout and can safely remove the "PS/2" line.

After you restart Xorg, both the internal and external mouse should be working. If you plug in the external mouse some time later, and the extermal mouse is not immediately recognized, you should be able to activate the mouse without restarting X by just switching to the text console and then switching back to X.

Disconnected Printer

Question:

I have a USB printer attached to a Suse Linux 9.3 system. Whenever the USB cable for the printer gets unhooked, the printer configuration stops working - even if I reboot and attach the cable to the same port where it was attached before. I have to delete the old printer configuration and reinstall the printer in Yast. Why is this necessary? Does the problem reflect some eternal characteristic of the USB subsystem? If so, is there some setting I can change in a configuration file that will fix the problem without requiring me to reinstall the printer?

Answer:

Frankly, I don't think that cups would change the printer configuration when you just unplug the printer. One explanation related to the case of an USB printer would be that the firmware of the printer must be uploaded to the printer again when you plug it in. If hotplug or udev "forget" this, the printer itself just won't respond to anything until a reboot or restart of the corresponding USB module forces an upload of the firmware. My advice in this case would just be, don't buy a printer that does not work out-of-the-box (i.e., which needs a firmware upload prior to normal operation).

Figure 1: Change the printer settings by clicking the right mouse button in the KDE printmanager "kcmshell printmgr".

My second guess is that the printer status in cups is just marked as "offline" when you unplug the printer, and cups is configured in a way that does not support automatic rescanning for the "back online" status. What you can do to verify this, is:

  1. Open the printer configuration window. In KDE, enter the following
    kcmshell printmgr
  1. Right-click on the printer and check if its status says "online." You can also restart/enable this printer with the right mouse button.