From Linux PARISC Wiki
Revision as of 17:17, 5 November 2013 by Deller (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


  • We currently only support 32-bit ELF executables. Initial bringup work was accomplished using HP-UX emulation, but that emulation has not been maintained. Eventually, we hope to have support for HP-UX 32-bit SOM executables working again, and add support for 64-bit ELF executables, both Linux & HP-UX. We're not promising to get all HP-UX binaries running on Linux. In particular those which are multithreaded are unlikely to ever be supported.
  • Please see this explanation.
  • Debian suggests several methods to acquire Official Install CDs.
    Pre-built 600+MB ISOs can be downloaded from: .de .se .ca.usa.
    Much smaller and less tested, daily snapshots have newer kernels on them. Caveat Emptor.
  • The full error message from the IODC (firmware) looks like:

     	ENTRY_INIT failed, status = -3: Cannot complete call without error   

    There are three likely causes for the ENTRY_INIT error and different machines may return different status numbers depending on the reason type of IO device:
    1. non-bootable CD drive (broken or incompatible)
    2. The CD drive block size (usually a jumper on the back) is not set to 512 byte blocks.
    3. The CD has bad blocks where boot data is expected (or is upside down in tray :^)

  • The How to Burn a Boot CD covers many of the issues below. The following steps should help the rule out common failures:

    1. Check the integrity of the CD image file used to burn the CD. The output of md5sum your_cd_img.iso should match the value found in md5sum.txt from the original site.
    2. Use sea ipl from the PDC menu prompt to search for bootable media (hard disk or CD). Interrupt "autoboot" to get a PDC (aka Boot Console Handler) command prompt. CD, disk, or tape drives with bootable media installed will be listed in sea output. sea is much faster if one specifies the HW Path (eg sea SCSI.3.0 ipl). Listen for the CD to spin up (a clue the CD is not broken) as sea tries to read the boot sectors off the CD drive. If a CD drive then shows up in the list, next step is to verify the CD does not have bad blocks in the vmlinuz or initrd data.
    3. Test the ability to boot by trying a HP-UX install disk then run sea command. If that works, the Debian CD was not burned correctly or has a defective boot sector(s). If sea doesn't work, then it's likely the CDROM drive is either broken, misconfigured, or just incompatible. Check CD-ROM drive data sheets to verify the drive is using 512byte sectors and not 2k sectors. The IODC (PARISC "BIOS") can only deal with 512 byte sectors. Some older CD-ROMs only support 2k sectors and can not be used to boot.
    4. Verify the integrity of the Debian CD. Reading the CD on another linux system using something like "dd if=/dev/cdrom of=/dev/null bs=2k". If all blocks are readable and a Windows machine was used to burn the CD, then the CD likely wasn't burned in "raw" mode and the boot blocks are mangled. Try burning the CD in "raw" mode. If the CD was burned without padding option, the CD integrity could also be checked with "dd if=/dev/cdrom | md5sum" and the result should match the value of the original iso image.

  • For newer workstations (4-digit B/C/J class), PDC will revert to using SERIAL_1 if a USB keyboard is not detected at boot up. For some models of older workstations, you can either remove the framebuffer card, or hold down TOC for ten seconds while booting up. However, this does not work on all models.
  • Please follow the Recipe. BTW, We've stopped using CVS for parisc-linux kernel work. Kudos to Matthew Wilcox for writing a PA-RISC GIT howto that I [ggg] could understand. It contains directions on how pull kernel sources, make diffs using git, and links to a few other practical examples on using git.
  • Yes. We merge between the PA-RISC Linux repository and Linus' tree regularly.
    Read the PA-RISC GIT howto to pull a source tree and then run:
     	git diff refs/tags/v2.6.28..HEAD   
    (substitute preferred tag for "v2.6.28") to get the current diff.

  • Randolph Chung wrote a small HOWTO just for YOU!

    Ok. It's not that small anymore. But not providing at least a few of the details listed in the HOWTO will just lead to folks (a) asking for the missing info and/or (b) folks ignoring you.
  • Occasionally, one needs to change the kernel boot parameters to boot a system. Check the release errata and search the parisc-linux mail archives for parisc specific options. You can also refer to the PALO section of our HOWTO.
    Two ways to modify kernel boot parameters via palo:
    • Interactive: During bootup press the escape-key to stop auto-boot. On older machines enter "BO scsi.X.0 IPL" and replace X with the SCSI ID of your boot-disc. Appending IPL directs palo to interact with the user and offer a menu to change the boot-parameters for this boot only.
      On newer systems, IPL isn't needed since the PDC will ask Interact with IPL (Y/N)?

Just enter Y here and palo will let you change the parameters.

    • Auto-boot: To change the palo/linux kernel parameters permanently, edit /etc/palo.conf and change the arguments to --commandline parameter. Most importantly run palo once to store the new kernel parameters on the boot disk. The new parameters will be effective for successive boots.

  • A long time ago, in a galaxy far, far away....well, not really. Just a long time ago Martin Petersen (with help from others) wrote this PARISC NFS-Root-HOWTO for a fledgling parisc-linux port. The "official" NFS-Root-Client-mini-HOWTO will probably serve you better. It's also called the "diskless root" if you want to search for more info.
    It's also worth mentioning the PA-RISC/Linux Boot HOWTO.
  • Yes! "resident" boot expert Martin Petersen knew you would ask! Martin wrote the PA-RISC RAID1 Boot HOW-TO to blaze a path for the weak and timid.
  • Lots of boot and some performance problems can be attributed to firmware "bugs". All machines print the PDC revision at boot up. Or once at "Main Menu>" or "BOOT_ADMIN>" one can print the PDC revision with "in fv" (c3000) or "in" (712) command. Putting more intelligence in any software module will increase the odds of having bugs. Since firmware updates (aka patches) are freely available (below), the latest firmware is required when reporting problems instead of attempting other workarounds. The official "front door" for all patches (Firmware, HPUX, MPE, OpenVMS, Tru64, Linux, ...) is the IT Resource Center. But if you know what you need, go directly to the catalog of firmware patches and then grab the correct firmware update from the HP FFS Patch Server. The PDC Patch Catalog lists firmware revs for systems which have upgradeable firmware. If it's not listed either you don't need a patch (yet :^) or it's not upgradeable. Systems older than 712 or 715's (eg 735) are only upgradeable via chip replacement. BEWARE: It's possible to kill a system by either upgrading the wrong firmware or the upgrade doesn't finish properly for any reason. Don't upgrade unless you have evidence of a PDC problem. Text files on the HP patch depot describe what was fixed in each revision since the machine model was released.
  • Check the contents of /etc/inittab and make sure the following lines exist and are uncommented.
    1:2345:respawn:/sbin/getty 38400 tty1
    2:23:respawn:/sbin/getty 38400 tty2
    3:23:respawn:/sbin/getty 38400 tty3
    4:23:respawn:/sbin/getty 38400 tty4
    5:23:respawn:/sbin/getty 38400 tty5
    6:23:respawn:/sbin/getty 38400 tty6
    Contributed by: Phillip Beal [[<>]]

  • Cannot access the Hardware Clock via any known method.
    What do I do? Create the special /dev/rtc device:
     	mknod /dev/rtc c 10 135   

  • Yes. In general it's possible to use use ISA cards in the EISA slots. We already had some success with ISA NE2000 clones and some other cards, but you need to tell the kernel via the eisa_irq_edge boot parameter which ISA IRQs should be available for ISA devices.
    See the next FAQ entry for details. Also note that busmastering ISA or EISA cards are not yet supported.
  • In order to get ISA IRQs working you'll need to tell the kernel which IRQs should be set to edge triggered mode and thus be available for ISA devices. Add the kernel boot parameter eisa_irq_edge=3,4,5,7,9,10,11,14,15 to the palo command line and replace the numbers in this example with the ISA IRQs you need for your cards.
  • All Linux kernels greater than version 2.4.18-pa45 - including all 2.6 Kernels - use the standard Linux input layer to access HIL-, PS/2 and USB keyboards and mice:

    To use your HIL-, PS/2- or USB-mouse with gpm modify your /etc/gpm.conf config file:

    To use your HIL-, PS/2- or USB-mouse with X-Windows (X11), configure either your /etc/X11/XF86Config-4 or /etc/X11/xorg.conf config file with following values:
    Section "InputDevice"
    Identifier "Keyboard"
    Driver "keyboard"
    Option "CoreKeyboard"
    #Option "XkbLayout" "de"

    Section "InputDevice"
    Identifier "Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "ImPS/2"
    Option "ZAxisMapping" "4 5"
    Alternatively you might download this XF86Config-4 file and adjust the resolution and screen color depth as described here and store your new config file to the /etc/X11/ directory.

  • In the 2.6 kernel series, we switched from a PA-RISC-only PS/2 mouse/keyboard driver to the standard Linux kernel PS/2 mouse and keyboard drivers. Hence, in order to get your PS/2 mouse/keyboard, which is either directly connected to your system or via a HIL&PS2-HUB, to work you'll have to enable
  • in addition to
  • You don't need these options for non-HIL PS/2 devices:

  • First ask yourself: Why do I need to run a 64-bit kernel?
    Since parisc-linux does not yet support 64-bit userspace, there is no advantage to be gained running a 64-bit kernel on a machine with less than 3.5GB of memory. In fact, there are many disadvantages including more potential bugs, bigger data structures, slightly less performance on many common workloads. Only PA-RISC 2.0 CPU can run a 64-bit kernel (aka `wide mode'). Check /proc/cpuinfo if you already have linux booted. Or check firmware output at power up time. Systems running the CPU clock speed slower than 160Mhz are PA 1.x and faster than 180Mhz are PA 2.0. Systems between 160Mhz and 180Mhz are either PA 1.1 (PCX-L2, eg C160L) or PA 2.0 (PCX-U, eg C160). Platform firmware also determines the type of kernel which can be used:
    • 64-bit Only : A500, L/N-class, rpXXXX, Superdome servers, and all PA-8800 CPUs must run a 64-bit kernel.
    • Dual Mode : B2000/C3000, similar J-class workstations and PA 2.0 D/K/R-class system firmware can be called from either 32-bit or 64-bit mode.
    • 32-bit Only : Workstations up to and including the J2240/C360 and servers of D/R-class have 32-bit firmware.
  • For those who do want to test 64-bit kernels on PA 2.0 machines with 32-bit firmware, recent 2.6 64-bit kernels will auto-detect the firmware type and switch to the correct `mode' (wide or narrow). Older kernels need to be built with the special configuration option `32-bit PDC' appropriately set. Enabling this option will switch the 64-bit kernel to narrow mode before calling 32-bit firmware.
  • First you have to start a telnet session on your lanconsole, login to GSP, and type 'CO' at the GSP prompt to get the system console. (You might need to type '^Ecf' to gain write access on it). Then you have to *escape* from the telnet session, by typing '^]' on a QWERTY keyboard ('^-AltGr-]' or '^$' on some AZERTY layouts). You will get a 'telnet>' prompt. Type 'send break', hit enter to validate. The next key you will hit will be sent as the SysRq, e.g. if you type 'h' it will display the available SysRq keys. You will have to start all over again from the escape sequence for each SysRq you will need to send.
  • This is currently a bug/feature related to the HIL drivers.
    In the HIL drivers we poll the HIL ports with a few timers simultanously and those timers seem to increase the ksoftirqd load a lot.
    But although the load seems to be very high, the machine will be fully functional at maximum speed and it seems to us as if this is only a cosmetical problem which is maybe caused by some bugs in the load calculation functions in the Linux kernel.
    Update: Guy Martin posted a patch which solves this issue, but this patch is sadly not acceptable for upstream inclusion.
  • Jan 8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf2 at ip=0x0008930b The message usually means the program in question is buggy and is not meeting address alignment requirements. The unaligned access is trapped and emulated by the kernel, so normally the message itself is simply informational.

    Like most architectures, PA-RISC loads (and stores) to half-words, words, doublewords have specific address alignment requirements. The address accessed must be divisible by the number of bytes being stored. E.G. word (32-bit) stores should access an address divisible by 4.
  • FX Graphic adapters are not (and will probably never be) supported as framebuffer devices, and don't have specific XFree drivers.

    That is to say these cards can only be used through STI Console. Hence, you can't use XFree with any FX card.
  • This may be because your card is running in double buffered mode. To check this, type 'co' and then 'mo' at the PDC menu prompt. If 'Double buffered' appears as part of the 'Class', select another monitor type - for instructions on how to do this, type 'help mo'.
  • Short Answer: Voodoo2/ATI Rage XL provide limited functionality.
    Long Answer: See the PA-RISC Graphics HOW-TO.

The glibc nscd daemon is broken since quite some time.
You may either just disable the nscd daemon, or alternatively put the following lines into your /etc/nscd.conf file:

	Broken on PA-RISC
	enable-cache        passwd        no

	# Broken on PA-RISC
	enable-cache        group        no 
Personal tools