Contents: 1. Introduction 1.1 Notation 2. Hatari issues 3. Building m68k kernel 4. Building root file system 4.1 As EXT2 HD image, from BusyBox 4.2 As EXT2 HD image, from klibc utils 5. Building initrd 6. Running Hatari 7. Debugging and profiling 8. Native bootstrap 9. Debian m68k install 9.1 Debian installer 9.2 Running initrd as normal disk 9.3 Bootstrapping Debian installation on PC 10. Linux kernel issues 10.1 Known issues 10.2 TODO / investigate more 11 User-space issues with 030 emulation 1. Introduction --------------- Here are instructions on building m68k Linux: - kernel - ramdisk - root file system And using them with Hatari. Build instructions are for Debian as that is the only Linux distribution still building latest SW package versions for m68k, in ports: http://ftp.ports.debian.org/debian-ports/pool-m68k/main/ But m68k gcc is available also on other distributions, along with tools for building the images (from packages in Debian ports). 1.1 Notation ------------ In examples, different execution environments are indicated by prompts: $ -- shell prompt # -- root shell prompt > -- Hatari debugger prompt "wget" examples do not give exact package names because versions in them change frequently. Replace "*" in those file names with the version available in the given remote directory! 2. Hatari issues ---------------- - LILO reset code has not yet been updated from Aranym's Falcon AfterBurner behavior to normal Falcon (they use different reset addresses), so "reboot" command fails with LILO - PC address points to ST-RAM in debugger even for emulated Linux code running in TT-RAM, because it is not MMU-translated => workaround: load Linux to ST-RAM when debugging/profiling - There are lot of ("--log-level debug" and profiler) warnings about memory accesses to >2GB range when programs do syscalls. An issue with Hatari high address memory setup, or another symptom of missing MMU-translation within Hatari? DEBUG: Your Atari program just did something terribly stupid: dummy_xlate($c00123ee) - Incomplete SCSI emulation: => workaround: have root file system on IDE master or slave Rootfs mount from SCSI device fails after following debug output: ------------------------------------------------------------ ... DEBUG: raw_scsi: selected id 0 DEBUG: raw_scsi_put_data got message c0 (1/1) DEBUG: raw_scsi_put_data got message c0 (1 bytes) DEBUG: raw_scsi: got command byte 1a (1/6) DEBUG: raw_scsi: got command byte 00 (2/6) DEBUG: raw_scsi: got command byte 3f (3/6) DEBUG: raw_scsi: got command byte 00 (4/6) DEBUG: raw_scsi: got command byte 04 (5/6) DEBUG: raw_scsi: got command byte 00 (6/6) TODO : HDC: Unsupported MODE SENSE command DEBUG: raw_scsi: no data, status = 2 DEBUG: raw_scsi: status byte read 02. Next=1 DEBUG: raw_scsi: message byte read 00. Next=1 DEBUG: raw_scsi: arbitration initiator id 7 (80) DEBUG: raw_scsi: arbitration DEBUG: raw_scsi: selected id 0 DEBUG: raw_scsi_put_data got message 80 (1/1) DEBUG: raw_scsi_put_data got message 80 (1 bytes) DEBUG: raw_scsi: got command byte 03 (1/6) DEBUG: raw_scsi: got command byte 00 (2/6) DEBUG: raw_scsi: got command byte 00 (3/6) DEBUG: raw_scsi: got command byte 00 (4/6) DEBUG: raw_scsi: got command byte 60 (5/6) DEBUG: raw_scsi: got command byte 00 (6/6) WARN : HDC: *** Strange REQUEST SENSE ***! DEBUG: raw_scsi: data in 22 bytes waiting DEBUG: raw_scsi: data in finished, 22 bytes: status phase DEBUG: DMA initiator recv PC=001ba66a DEBUG: SCSI BUS reset sd 0:0:0:0: Device offlined - not ready after error recovery sd 0:0:0:0: [sda] Asking for cache data failed sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] Attached SCSI disk VFS: Cannot open root device "/dev/sda" or unknown-block(8,0): error -6 ------------------------------------------------------------ 3. Building m68k kernel ----------------------- 0. Install generic build tools: $ sudo apt install bc bison flex 1. Install compiler: $ sudo apt install gcc-m68k-linux-gnu 2. Get latest upstream kernel release sources (without history): $ git clone --depth 1 --branch v6.11 \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ cd linux 3. Apply Linux issue workaround patches: $ git am /path/to/hatari/tools/linux/000*.patch 4. Get Hatari compatible configuration: $ cp /path/to/hatari/tools/linux/kernel.config .config 5. Compile configured kernel: $ ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- make -j4 vmlinux Notes: - You can fine-tune kernel config for your requirements with: $ ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- make -j4 menuconfig - Using "optimize for size" instead of "optimize for performance" reduced (stripped) kernel image by ~15% - Normal Linux builds require 030 (or better) with MMU and FPU (only uCLinux would work on 68000 without MMU) - Using included kernel.config file as-is, builds non-modular kernel that includes all relevant features for mounting root fs directly. It saves bootup time compared to using initramfs for loading the needed external modules - Bootup works faster when kernel is uncompressed, as uncompression would happen in emulated code => do not compress kernel 4. Building root file system ---------------------------- This is common part for both examples below (if you already have a directory named disk/, rename it, or use another name). 1. Create root file system directories: $ mkdir disk $ cd disk $ mkdir -p dev bin etc lib mnt proc root run sbin sys tmp usr/bin usr/sbin 2. Add minimal init script for mounting virtual file systems before starting shell: $ cp -a /path/to/hatari/tools/linux/init.sh init 3. Add a user: $ echo "root:x:0:0:root:/root:/bin/sh" > etc/passwd 4. And basic terminal descriptions: $ cp -ar /lib/terminfo/ lib/ 4.1 As EXT2 HD image, from BusyBox ---------------------------------- This builds a minimal hard disk root file system with BusyBox. BusyBox is a multi-call binary, which performs the same job as many separate programs, based on the (symlink) name with which it is invoked. For more info, see "man busybox" (after installing BusyBox to host). 5. Fetch statically linked m68k BusyBox and extract it: $ wget http://ftp.ports.debian.org/debian-ports/pool-m68k/main/b/busybox/busybox-static_*_m68k.deb $ ar x busybox-static_*_m68k.deb $ tar xvf data.tar.xz --wildcards *bin/busybox 6. Install qemu user space emulation to query m68k busybox, so that symlinks can be added for the tools it lists: $ sudo apt install qemu-user $ /path/to/hatari/tools/linux/symlink-busybox.sh 7. Cleanup directory content: $ rm *.tar.* debian-binary 8. Make 4MB EXT2 HD image out of it: $ cd .. $ /sbin/mkfs.ext2 -t ext2 -L BUSYBOX -d disk/ rootfs.img 4M 4.2 As EXT2 HD image, from klibc utils -------------------------------------- This builds a minimal hard disk root file system with kernel "libc" utilities intended for initramfs. These utilities are separate binaries (not symlinks like with BusyBox) and they're much more limited than BusyBox; they lack many of the standard options and shell does not e.g. have file name completion. In total they take only few hundred KB of space though. 5. Fetch klibc library and utility packages: $ wget http://ftp.ports.debian.org/debian-ports/pool-m68k/main/k/klibc/libklibc_*_m68k.deb $ wget http://ftp.ports.debian.org/debian-ports/pool-m68k/main/k/klibc/klibc-utils_*_m68k.deb 6. Extract them: $ ar x libklibc_*_m68k.deb $ tar xvf data.tar.xz $ ar x klibc-utils_*_m68k.deb $ tar xvf data.tar.xz 7. Move utilities to bin/ and clean directory: $ mv usr/lib/klibc/bin/ . $ rm -r *.tar.* debian-binary $ cd .. 8. Make 4MB EXT2 HD image out of it: $ /sbin/mkfs.ext2 -t ext2 -L KLIBC -d disk/ rootfs.img 4M Notes: - these utilities would fit even to a floppy image: $ zip2st disk/ klibc.st But FAT file system cannot be used for Linux root fs because it is lacking security features required from one. 5. Building initrd ------------------ After creating either of above root file systems, you can use the same content also to create an example initrd / initramfs. 9. Package directory content with cpio and compress it with LZO: $ cd disk/ $ find | cpio -R 0:0 -H newc --create | lzop -9 > ../initrd.img Notes: - *Initrd is unnecessary* when kernel includes everything needed for mounting the real root file system, like is the case *with the provided kernel.config*. Initrd is required only if you e.g. need to enter password to decrypt the disk or load additional kernel module(s) before mounting the root file system. - Initrd resides in / uses RAM, so you're better of mounting the real root fs directly. if you're tight on memory, but still need initrd, minimize its size and make sure kernel can free it after pivoting to real root fs. - Kernel will need to extract initrd contents from CPIO archive loaded to RAM. Archive is freed after extraction, but before that a significant amount of extra RAM is needed for it. - Kernel can handle both compressed and uncompressed initrd. Compressed initrd takes less RAM during CIO archive extraction, but its decompression slows boot significantly. - Above used LZO compression provides faster decompression speed, gzip/deflate better compression ratio. Both are enabled in included kernel.config. One can enable from kernel config extra compression algorithms with better compression ratios, but they are significantly slower. 6. Running Hatari ----------------- 1. Set suitable options in lilo.cfg, for example: ------------------------------------- [LILO] Kernel = vmlinux-v6.11 Symbols = System.map-v6.11 Ramdisk = Args = video=atafb:sthigh console=tty KernelToFastRam = FALSE ------------------------------------- (See lilo.cfg in doc/ directory for more info.) 2. Start Hatari: $ hatari --log-level info \ --fast-forward on --fastfdc on --timer-d on \ --machine falcon --dsp off --fpu 68882 \ --cpuclock 32 --cpu-exact off --compatible off \ --mmu on -s 14 --ttram 64 --addr24 off \ -c lilo.cfg --natfeats on \ 2a) with root fs on disk: --ide-master rootfs.img \ --lilo "debug=nfcon root=/dev/sda ro init=/init" 2b) with root fs being initrd specified in lilo.cfg: --lilo "debug=nfcon root=/dev/ram ro init=/init" Options explanation (these can also be set in lilo.cfg): - video=atafb:sthigh -- frame buffer starts in ST-high (mono is fastest mode with large enough resolution) - console=tty -- console output goes to frame buffer - debug=nfcon -- kernel debug messages go to Hatari console - root= -- what device is used for mounting root file system - ro -- mount it read-only - init= -- run given executable / script as first process Other notes: - Hatari CPU cache & prefetch emulation is disabled as otherwise there are random bus errors & failures on Linux system calls - Keep "init=" last on "--lilo" option kernel command line, otherwise kernel may give arguments after it also to init! - Kernel does not need DSP, and avoiding its emulation with "--dsp off" (about) doubles "--fast-forward on" speed 7. Native bootstrap ------------------- Real HW does not have LILO, so a separate bootstrap program is needed for loading the kernel into RAM and executing it from there. Following shows easiest method to simulate that with Hatari. 1. Get bootstrap program: $ mkdir gemdos-hd $ cd gemdos-hd $ wget https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/atari/bootstra.tos 2. Tell bootstrap program to load kernel to ST-RAM and whole command line to give to the kernel: $ echo "-s -d -k vmlinux root=/dev/sda ro debug=nfcon video=atafb:sthigh console=tty init=/init" > bootargs $ cd .. 3. Get kernel to bootstrap: $ cp /path/to/m68k-kernel/vmlinux gemdos-hd/ 4. If you do not have a TOS ROM image, download latest EmuTOS release from: https://sourceforge.net/projects/emutos/files/emutos/1.3/emutos-1024k-1.3.zip/download and extract it: $ unzip emutos-1024k-1.3.zip 5. Then run Hatari with them: $ hatari --trace os_base --log-level info \ --tos emutos-1024k-1.3/etos1024k.img \ --fast-forward on --fastfdc on --timer-d on \ --machine falcon --dsp off --fpu 68882 \ --cpuclock 32 --data-cache off \ --mmu on -s 14 --ttram 64 --addr24 off \ --natfeats on --ide-master rootfs.img \ gemdos-hd/bootstra.tos Hatari notes: - Because GEMDOS HD is specific to TOS, it is not accessible from Linux - Because TOS does not have driver for the Linux disk, and GEMDOS HD is assigned to C:, IDE content is not accessible from TOS On real HW: - Linux rootfs would be put to a partition (e.g. "sda2"), it would not start from IDE drive first sector ("sda") - NatFeats is not available, so debug option can be removed, or debug device set to a more suitable one (e.g. serial) 8. Debugging and profiling -------------------------- There are few ways to investigate what happens at boot: - Asking kernel to give debug output for module initializations with "initcall_debug" kernel command line option - Disabling individual init calls with "initcall_blacklist=" to see whether boot proceeds (better) without them - Tracing kernel function calls with Hatari "trace cpu_symbols" debugger command and the "--trace cpu_symbols" option - Profiling what the kernel does Tracing and "initcall_debug" will give a lot of output so save it also to a file: $ hatari ... 2>&1 | tee output.txt Tracing and profiling both require symbols file produced during kernel build. If that file is listed in lilo.cfg, symbols will be automatically loaded before Linux boots. For now, all debugging and profiling should be done with kernel loaded to ST-RAM (see Hatari issues section). For that, its size needs to be <8MB uncompressed, otherwise it wo not work from ST-RAM. Related lilo.cfg options are: KernelToFastRam = FALSE Symbols = Symbols.map To verify that symbols loaded correctly, one can check in debugger e.g. whether nf_call (NatFeats entry point) looks as expected: ---------------- > d nf_call $00008230 : 7301 DC.W $7301 $00008232 : 4e75 rts ---------------- To profile whole bootup, profiling needs to be enabled right from the start, and stopped (e.g. by breakpoint) at appropriate point. This debugger command file does profiling until first brk() syscall (i.e. shortly after kernel starts init and that does its first alloc): --- profile-boot.ini --- profile on b pc = sys_brk ------------------------ Adding that to Hatari options with "--parse profile-boot.ini", will start profiling from the very first executed instruction. After debugger gets invoked on first brk() syscall function call / breakpoint, one can save profile with: > profile save profile.txt Resulting file can be post-processed with: $ hatari_profile -st -a System.map profile.txt To see how much emulated time the profiled part took, and to get lists of functions taking most cycles / time, using most instructions, and being called most. To debug and get back traces to where "die_if_kernel" bug handler gets called, one can use following files: ---- bt-show.ini ---- profile stack ---- bt-init.ini ---- profile on b pc=die_if_kernel :noinit :trace :file bt-show.ini ------------------------ And start hatari with "--parse bt-init.ini" option. Backtraces to any other functions listed in kernel symbol file can caught the same way. Breakpoint options: * :file -- execute debugger commands from given file when breakpoint is hit * :trace -- continue running without dropping to debugger * :noinit -- no reset for profile/caller info when breakpoint is hit (Last option is needed only for the "profile stack" command.) What symbols are in the symbol file dictates what one sees with many of the debugger commands. If one does just tracing and profiling, one can reduce symbol warnings from Hatari by removing unnecessary symbols from the used symbols file: $ grep ' [tT] ' Symbols.map > code-symbols.map If one is interested only of e.g. tracing kernel syscalls, one should load just those to debugger: $ grep ' [tT] sys_' Symbols.map > syscall-symbols.map ... > symbols syscall-symbols.map > trace cpu_symbols (System call info is naturally interesting only after user-space processes are running & calling them.) If you see errors like these on Linux console: hda: possibly failed opcode: 0x39 hda: possibly failed opcode: 0x30 (On Linux v5.4, IDE is on 'sda' instead of 'hda'.) Those are IDE write command opcodes. Make sure your IDE image actually *is* writable and try again. 9. Debian m68k install ---------------------- 9.1 Debian installer -------------------- These are setup instructions for testing Debian installer in Hatari. 0. Work directory: $ mkdir -p debian/installer $ cd debian/installer 1. Get latest Debian installer (kernel + initrd images): $ wget https://cdimage.debian.org/cdimage/ports/debian-installer/2024-02-25/m68k/debian-installer-images_202306XX_m68k.tar.gz $ tar xvf debian-installer-images*.gz 2. Set up lilo.cfg with a framebuffer mode supported by Debian installer (it needs at least 16 colors to be usable): $ cat > lilo.cfg [LILO] Kernel = installer-m68k/current/images/kernels/vmlinux Args = video=atafb:vga16 console=tty Ramdisk = installer-m68k/current/images/nativehd/initrd.gz KernelToFastRam = FALSE RamdiskToFastRam = TRUE ^D 3. Get ISO image release matching installer & kernel (checksum files are in same directory): $ wget https://cdimage.debian.org/cdimage/ports/snapshots/2024-02-25/debian-12.0.0-m68k-NETINST-1.iso 4. Try running Hatari with them: $ hatari --log-level debug \ --fast-forward on --fastfdc on --timer-d on \ --machine falcon --dsp off --fpu 68882 \ --cpuclock 32 --data-cache off \ --mmu on -s 14 --ttram 128 --addr24 off \ --monitor vga -c lilo.cfg --natfeats on \ --ide-master debian-12.0.0-m68k-NETINST-1.iso \ --lilo "debug=nfcon root=/dev/ram init=/init" NOTE: Hatari does not support networking so network install obviously does not work. There are no ready made images of pre-installed and up to date m68k Debian installs either. TODO: kernel panics when init crashes. 9.2 Running initrd as normal disk --------------------------------- If Debian boot has issues already in its initrd, you could try running it as normal disk with monolithic kernel, or using modular kernel with a working initrd. Converting initrd to a normal EXT2 disk partition, and using fakeroot session to retain file properties requiring root rights: $ mkdir initrd $ fakeroot /bin/bash # cd initrd # zcat ../installer-m68k/current/images/nativehd/initrd.gz | cpio -i # cd .. # /sbin/mkfs.ext2 -t ext2 -L INITRD -d initrd initrd.img 32M # exit TODO: init is dynamically linked Busybox and crashes immediately. If it's replaced with statically linked one, that crashes to first "mkdir" (or "ls") call on just mounted "/run": ------------------------ tmpfs /run tmpfs nosuid,size=10%,mode=755 0 0 ------------------------ 9.3 Bootstrapping Debian installation on PC ------------------------------------------- Doing first stage of setting up minimal m68k Debian system image (without package PGP signing checks), as root: # apt install debootstrap # debootstrap --foreign --arch=m68k --no-check-gpg sid debian-chroot http://ftp.ports.debian.org/debian-ports/ # cp -a /path/to/hatari/tools/linux/init.sh debian-chroot/init # /sbin/mkfs.ext2 -t ext2 -L DEBIAN -d debian-chroot debian.img 512M # chown $USER.$USER debian.img NOTE: debootstrap needs to be done on a partition that is not mounted with "noexec" or "nodev" option, otherwise it fails! To finish bootstrapping, one would need to boot it on m68k system and run "debootstrap --second-stage". TODO: test again whether there are improvements to last status: - Hatari: debootstrap fails to kernel oops - m68k system-qemu: does not support required HW - m68k user-qemu (from Debian Bookworm): does support m68k binaries - Aranym: ------------------------------------------------------------ $ cat > linux.config # NOTE, run with: aranym-mmu -l [GLOBAL] FastRAM = 64 [LILO] Kernel = vmlinux Args = video=atafb:vga16 console=tty debug=nfcon root=/dev/sda ro init=/init # 512MB EXT2 image with mkfs.ext2 (Cylinders = 2 * size in MB) [IDE0] Cylinders = 1024 Heads = 16 SectorsPerTrack = 64 Present = Yes IsCDROM = No ByteSwap = Yes ReadOnly = Yes Path = debian.img ModelName = Debian-m68k ^D $ aranym-mmu -l linux.config ------------------------------------------------------------ 10. Linux kernel issues ----------------------- 10.1 Known issues ----------------- - Old (4.x?) Linux versions do not work if kernel is loaded to TT-RAM Workaround: Load kernel to ST-RAM or use more recent kernel version - Hatari debug output shows IDE and DSP reset messages on Falcon at 2Hz (from floppy media change detection) if Linux is started with --lilo, instead of from TOS. This is because TOS initializes PSG port-A register bits to sensible values and Linux does not. Workaround: included kernel patch - Atari TT boot freezes with constant "unexpected interrupt from 112" messages, due to Linux SCU register setup regression. Workaround: use >=6.11 kernel, or kernel patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f70065a9fd988983b2c693631b801f25a615fc04 10.2 TODO / investigate more ---------------------------- - Kernel does not recognize ACSI drives at all, although kernel reports finding Atari ACSI HW: ------------------------------------------------------------ Atari hardware found: TT_SHIFTER ST_MFP TT_MFP TT_SCSI_DMA TT_SCSI YM2149 PCM SCC_DMA SCC MICROWIRE TT_CLK FDC_SPEED ACSI ... scsi host0: Atari native SCSI, irq 39, io_port 0x0, base 0x0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { } ... Core driver edition 01.06 : TT driver edition 00.03 Write will use 4 fragments of 32768 bytes as default NET: Registered PF_PACKET protocol family VFS: Cannot open root device "/dev/sda" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions: 0200 3280 fd0 (driver?) 0201 3280 fd1 (driver?) 0100 4096 ram0 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ------------------------------------------------------------ Only SCSI & IDE drives are recognized - with Hatari 2.5, Linux works again on 040 & 060, when CPU data cache emulation is disabled (with few previous Hatari versions, there was panic on reaching user-space). With data cache emulation, 060 boot crashes to double bus error, and 040 boot freezes early on. Although screen is black, CPU trace indicates latter being a panic. This did not happen with 2019 v2.3-dev Git version (and Linux version of that time). Linux also boots fine on real 060 Falcon: https://www.youtube.com/watch?v=8Sriz45Z4oM - Busybox "halt" & "reboot" do nothing, although klibc versions work fine 11. User-space issues with 030 emulation ---------------------------------------- These problems happen when either (or both) cycle-exact or prefetch emulation is enabled for 030 (with MMU). (If both cycle-exact and prefetch emulation are disabled, Hatari will disable also CPU data cache emulation.) On quick testing, klibc based (dynamically linked) tools do not have problems, but tools in (statically linked) BusyBox do have a lot of problems: http://ftp.ports.debian.org/debian-ports/pool-m68k/main/b/busybox/busybox-static_1.36.1-9_m68k.deb - following BusyBox commands segfault before outputting anything: adjtimex, arch, awk, basename, blockdev, chgrp, chmod, chown, chroot, chvt, clear, cp, date, df, dirname, dumpkmap, env, expr, find, fold, free, getopt, head, hexdump, hostid, hostname, id, ionice, ip, ipcalc, groups, killall, link, ln, logname, ls, lsmod, md5sum, mkdir, mkfifo, mknod, mkpasswd, mktemp, modinfo, modprobe, mv, nameif, nproc, ps, readlink, realpath, renice, reset, rm, rmdir, seq, sha*sum, sort, start, stty, sync, sysctl, taskset, touch, umount, which, uname, uptime, usleep, w, who, whoami, xargs, yes And for example following do not segfault: arping, arp, ascii, ash, bc, bzcat, cal, cat, cmp, dmesg, du, echo, egrep, expand, factor, false, fdisk, fgrep, grep, gunzip, gzip, halt, hwclock, ifconfig, kill, last, less, more, mount, netstat, nologin, nsenter, nslookup, openvt, patch, pidof, ping, ping6, poweroff, printf, pwd, uname, sed, set, setsid, sh, sleep, strings, syslogd, tail, tee, telnet, test, top, traceroute, true, uniq, vi, watch, wget - "sed" does not segfault, but does not work correctly either. - 'setsid cttyhack' (without "-c" option) freezes (shell or kernel?) ---- TODO: rest is old information for 5.x kernels and old Hatari versions that needs to be re-checked! - Some Busybox commands (e.g. 'setsid') randomly hang kernel v5.2, with Hatari showing following: ------------------------------------------------------------ - 1. 0x048fe8: vprintk_func +0x4c - 2. 0x048cda: printk +0xc - 3. 0x004d08: show_registers +0x6c - 4. 0x004fae: die_if_kernel +0x38 - 5. 0x0052e4: buserr_c +0x102 - 6. 0x0027c2: show_registers -0x24da (buserr +0x1a) - 7. 0x004fae: die_if_kernel +0x38 ... - 38200. 0x004fae: die_if_kernel +0x38 - 38201. 0x0052e4: buserr_c +0x102 - 38202. 0x0027c2: show_registers -0x24da (buserr +0x1a) - 38203. 0x004fae: die_if_kernel +0x38 ------------------------------------------------------------ - Tracing (just "strace -f -e execve") WWS window server seems to fail every time: ------------------------------------------------------------ *** LINE 1111 *** FORMAT=0 Current process id is 37 BAD KERNEL TRAP: 00000000 PC: [<000029a0>] user_inthandler+0x4/0x20 SR: 2c08 SP: 660bea93 a2: 00020370 d0: c003dbec d1: 00004b6c d2: 00000649 d3: c003d2d8 d4: c0035000 d5: c001ed3c a0: c0035000 a1: c003c978 Process wserver (pid: 37, task=8ce40330) Frame format=0 Stack from 0098dff8: ... Disabling lock debugging due to kernel taint Data read fault at 0xc09ca958 in Super Data (pc=0x2ecc) BAD KERNEL BUSERR Oops: 00000000 PC: [<00002ecc>] user_disable_single_step+0x16/0x2a SR: 2200 SP: a4351113 a2: 00925590 d0: 00000018 d1: 00000018 d2: 00000007 d3: 00000000 d4: 00010000 d5: 00000018 a0: c09ca958 a1: 0098faa0 Process strace (pid: 34, task=be6fd4ba) Frame format=B ssw=0365 isc=0004 isb=5c88 daddr=c09ca958 dobuf=0098faa0 baddr=c09ca958 dibuf=c09ca958 ver=0 Stack from 00977ee8: ... Call Trace: [<0002cef2>] ptrace_resume+0x34/0xb6 [<0002d830>] ptrace_request+0x76/0x4ce [<0025534c>] radix_tree_lookup+0x16/0x1c [<00002f9c>] arch_ptrace+0xa8/0x30a [<0002d638>] sys_ptrace+0x228/0x334 [<000028c4>] syscall+0x8/0xc ------------------------------------------------------------ Whereas tracing a simpler program like "echo" fails only randomly: ------------------------------------------------------------ *** LINE 1111 *** FORMAT=0 Current process id is 50 BAD KERNEL TRAP: 00000000 PC: [<00002988>] user_inthandler+0x4/0x20 SR: 2d08 SP: 2612bd53 a2: 000bc004 d0: d0097d7a d1: 00029db4 d2: 000037cf d3: d002cac0 d4: d0000000 d5: c001ed3c a0: d0000000 a1: d001c104 Process strace (pid: 50, task=80e4cce9) Frame format=0 Stack from 00955ff8: ... ------------------------------------------------------------