I'm attempting to run 32 bit linux off of a usb for an old XP machine. There are important files on the computer's base drive, so formatting or partitioning isn't on the cards. So far I've tried AntiX and Debian, and in both cases I was sent straight to grub repair with the error "/boot/grub/i386-pc/normal.mod cannot be found". Using grub rescue I identified the correct partition, and can use ls to see the list of folders to find the /boot folder, however any attempt to ls into the boot folder produces an empty line before returning the command prompt. Examining the usb with a different computer, the normal.mod file is there in its correct place, however the boot folder and a few other folders cannot be written to or modified due to permission issues which I can't figure out. My best guess is that grub simply isn't allowing itself to read the boot folder, but I'm not sure

I'm on Debian 7.9 (wheezy) x64, and I would like to install build-essential:i386. I already added i386 in dpkg --architecture, updated aptitude and installed java-jdk-1.6:i386 successfully. BTW, no matter how I try, build-essential systematically generates an error of dependencies with: apt-get install build-essential:i386 Depend : dpkg-dev:i386 (>= 1.13.5) E: Unable to correct problems, you have held broken packages... If someone has an idea... Thanks. Also, I found this on [Debian Mailing Lists - Re: cross-build-essential](https://lists.debian.org/debian-embedded/2012/07/msg00005.html) > > Say I want to have the build-essential for i386 installed on amd64. I could install build-essential:i386, replacing gcc/g++:amd64 with gcc/g++:i386. Wouldn't that give me everything needed to cross-compile for i386? > > In that case, yes, because you can run x86 code on an AMD64 or Intel 64 CPU. Though you would indeed be replacing gcc-4.7:amd64 etc. with gcc-4.7:i386 etc. as the packages aren't co-installable with themselves. Is it true?

My college provides a virtual machine (SliTaz VM, possibly an old Linux distro) to run veriluoc which is a software to design and simulate logic gates. The problem is that VM was designed to run on x86/x86_64 hardware. But I need it to run it on my M2-based(Arm) Macbook. I have been trying to use qemu and UTM to run it, with no success. The exact problem UTM displays is:

Booting SliTaz GNU/Linux (cooking) (Kernel vmlinux-2.6.37-slitaz)
Filesystem type is ext2fs, partition type 0x83
   [Linux-bzImage, setup=0x3400, size=0x25d4a0]
ehci_hcd 000:00:1d.7: init 0000:00:1d.7 fail, -16
i8042.c: No controller found.
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Pid: 1, comm: swapper Not tainted 2.6.37-slitaz #2
Call Trace:
 [] ? printk+0xf/0x11
 [] panic +0x50/0x14b
 [] mount_block_root+0x1e5/0x1f9
 [］？sys_mknod+Ox13/0x15
 [] mount_root+0x4c/0x54
 [1 prepare_namespace+0x140/0x171
 [] kernel_init+0x17f/0x18e
 [] ? kernel_int+0×0/0×18e
 [] kernel_thread_helper+0x6/0x10

No success either after searching the term VFS: Unable to mount root fs on unknown-block(0,0), or changing the disk type.

(This is in the context of x86-64 Linux.) I am trying to write a high-reliability userland executable, and I have total control over the generated assembly. I don't want to rely on automatic stack allocation, so I would like to put the stack in a known location. Suppose I have calculated that my program uses at most 414 bytes of stack space (exactly). Is it safe to allocate 414 bytes in the .bss section and point RSP to the top? I want to ensure that no bytes outside this region are touched by stack management at any point. While I can be sure that *my* program won't write outside the region, I need to make some syscalls (using the syscall instruction), and I think at least some part of the kernel code operates in the calling executable context. Will it smash my stack? Also, interrupts can happen at any point in the program, and the story behind the "Red Zone" seems to suggest that an arbitrarily large region beyond RSP-128 can be written to at will by interrupt handlers, possibly mangling my data. What kinds of guarantees do I have about this behavior?

I am currently researching the Linux kernels usage of virtual address spaces. I understand the benefits of having those, how page table walks work in x86, and the layout of the virtual address space . Here is the part I do not understand: During a lecture of mine, it was explained that the linux kernel uses an "identity mapping" in kernel space. Meaning: In kernel space, you can translate any virtual address to its physical address by subtracting a constant number. This number is often referred to as the PAGE_OFFSET and is different depending on 64bit vs 32bit, 4 Layer vs 5 Layer Address translation and may also be configured . kASLR increases the PAGE_OFFSET by a random amount on every boot as a security measure. I have seen this explained in many places, but most of them are a bit old: https://stackoverflow.com/a/36640733/15113903 https://stackoverflow.com/questions/24632905/mapping-of-kernel-virtual-address-directly?rq=1 The most recent implicit explanation is that volatility3 seems to rely on this identity mapping when figuring out the kASLR offset of a memory dump . Now: (Why) is the Kernel virtual address space (still) that way? Are there performance benefits? Is it necessary for some reason? Is it some heritage from earlier days? How likely is it to change in the near future? Thanks

I'm using 64 bit Kali Linux, previously installed i386 architecture and now I want to remove it, because it downloads about 30Mb data for 32bit package every time apt update. I tried dpkg --remove-architecture i386, it failed with *dpkg: error: cannot remove architecture 'i386' currently in use by the database* Google says the i386 packages should be removed first, but some package like "gcc-12-base:i386, libc6:i386, libcrypt1:i386, libgcc-s1:i386" cannot be removed, how to solve it?

Recently, I tried installing Lutris and Wine on my machine (which uses Debian 12 as its operating system with a 64-bit architecture and Plasma for my desktop). First, I installed Wine via this guide and everything ran smoothly; there were no errors and I am successfully able to run wine via my terminal. Here are the commands that I ran in accordance with the guide: sudo dpkg --add-architecture i386 sudo mkdir -pm755 /etc/apt/keyrings wget -O - https://dl.winehq.or /wine-builds/winehq.key | sudo gpg --dearmor -o /etc/apt/keyring /winehq-archive.key - sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/debian/dists/bookworm/winehq-bookworm.sources sudo apt update sudo apt install --install-recommends winehq-stable Next, I tried installing Lutris via this guide and this video (in the video, apparently he just runs the commands found on the guide accordingly, i just though I should include it just in case). When doing so, however, "broken" dependencies were reported via apt, so I ran sudo apt --fix-broken install. After doing this, I again ran sudo apt install lutris, and everything seemed to have worked correctly. Here are the commands that I ran in accordance with the guide (after using --fix-broken for apt install of course): echo "deb [signed-by=/etc/apt/keyrings/lutris.gpg] https://download.opensuse.org/repositories/home:/strycore/Debian_12/ ./" | sudo tee /etc/apt/sources.list.d/lutris.list > /dev/null wget -q -O- https://download.opensuse.org/repositories/home:/strycore/Debian_12/Release.key | gpg --dearmor | sudo tee /etc/apt/keyrings/lutris.gpg > /dev/null sudo apt update sudo apt install lutris Following this, of course, I tried running Lutris via my desktop, but was told that it could find no such application: I believe that perhaps the path used for running Lutris is for some reason incorrect/unknown. I am not very familiar with how Linux runs and/or identifies/recognizes applications nor exactly what Plasma KDE's application settings *for* Lutris (in this case) mean, but as you can see, there is no specified "workpath" (which may be important): How exactly would I locate/specify the correct path for running Lutris (assuming this is the problem)? I welcome any help pertaining to this issue (as well as any links to potentially more extensive/capable guides and/or documentation) and it is greatly appreciated. Additionally, this is my first post on this site, so please tell me if this question is not appropriate (or should be formatted differently).

I'm setting up NixOS 24.05 and I'm using the equivalent version of [Home Manager](https://github.com/nix-community/home-manager/) . I'm trying to move the directory for GNUPG to $HOME/.local/share/gnupg also known as $XDG_DATA_HOME/gnupg. I know that XDG_DATA_HOME is set correctly prior to making this question. Running gpgconf --list-dirs gives me the following output:

sysconfdir:/etc/gnupg
bindir:/nix/store/wfwk6kv1mp5v94dly55c3ql1rwsqrky0-gnupg-2.4.5/bin
libexecdir:/nix/store/wfwk6kv1mp5v94dly55c3ql1rwsqrky0-gnupg-2.4.5/libexec
libdir:/nix/store/wfwk6kv1mp5v94dly55c3ql1rwsqrky0-gnupg-2.4.5/lib/gnupg
datadir:/nix/store/wfwk6kv1mp5v94dly55c3ql1rwsqrky0-gnupg-2.4.5/share/gnupg
localedir:/nix/store/wfwk6kv1mp5v94dly55c3ql1rwsqrky0-gnupg-2.4.5/share/locale
socketdir:/run/user/1000/gnupg
dirmngr-socket:/run/user/1000/gnupg/S.dirmngr
keyboxd-socket:/run/user/1000/gnupg/S.keyboxd
agent-ssh-socket:/run/user/1000/gnupg/S.gpg-agent.ssh
agent-extra-socket:/run/user/1000/gnupg/S.gpg-agent.extra
agent-browser-socket:/run/user/1000/gnupg/S.gpg-agent.browser
agent-socket:/run/user/1000/gnupg/S.gpg-agent
homedir:/home/hanna/.gnupg

Upon setting the GNUPGHOME environment variable or using Home Manager's programs.gpg.homedir option, neither of these resulted in the homedir setting changing in gpgconf and thus the directory always being created at that path. It does not seem to be respecting any settings I am setting to change this, and I'm hoping someone can help with this.

I cannot get Unicode glyphs to render on Monjaro i3. I have installed a bunch of noto fonts, including noto-fonts, noto-fonts-cjk, noto-fonts-emoji, noto-fonts-extra, ttf-noto-nerd. When I run fc-match with an unrecognised Unicode character, it supposedly matches the correct font. This is for U+F312:

fc-match ""                                                                                                                                                                                      
NotoSans-Regular.ttf: "Noto Sans" "Regular"

I have run fc-cache -fv and rebooted multiple times.

fc-cache -fv
Font directories:
	/home/aidanb/.local/share/fonts
	/usr/local/share/fonts
	/usr/share/fonts
	/var/lib/snapd/desktop/fonts
	/home/aidanb/.fonts
	/usr/share/fonts/OTF
	/usr/share/fonts/TTF
	/usr/share/fonts/adobe-source-code-pro
	/usr/share/fonts/cantarell
	/usr/share/fonts/droid
	/usr/share/fonts/encodings
	/usr/share/fonts/gsfonts
	/usr/share/fonts/liberation
	/usr/share/fonts/misc
	/usr/share/fonts/noto
	/usr/share/fonts/noto-cjk
	/usr/share/fonts/encodings/large
/home/aidanb/.local/share/fonts: caching, new cache contents: 1 fonts, 0 dirs
/usr/local/share/fonts: skipping, no such directory
/usr/share/fonts: caching, new cache contents: 0 fonts, 11 dirs
/usr/share/fonts/OTF: caching, new cache contents: 23 fonts, 0 dirs
/usr/share/fonts/TTF: caching, new cache contents: 554 fonts, 0 dirs
/usr/share/fonts/adobe-source-code-pro: caching, new cache contents: 30 fonts, 0 dirs
/usr/share/fonts/cantarell: caching, new cache contents: 6 fonts, 0 dirs
/usr/share/fonts/droid: caching, new cache contents: 27 fonts, 0 dirs
/usr/share/fonts/encodings: caching, new cache contents: 0 fonts, 1 dirs
/usr/share/fonts/encodings/large: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/gsfonts: caching, new cache contents: 35 fonts, 0 dirs
/usr/share/fonts/liberation: caching, new cache contents: 12 fonts, 0 dirs
/usr/share/fonts/misc: caching, new cache contents: 125 fonts, 0 dirs
/usr/share/fonts/noto: caching, new cache contents: 2137 fonts, 0 dirs
/usr/share/fonts/noto-cjk: caching, new cache contents: 80 fonts, 0 dirs
/var/lib/snapd/desktop/fonts: skipping, no such directory
/home/aidanb/.fonts: skipping, no such directory
/usr/share/fonts/OTF: skipping, looped directory detected
/usr/share/fonts/TTF: skipping, looped directory detected
/usr/share/fonts/adobe-source-code-pro: skipping, looped directory detected
/usr/share/fonts/cantarell: skipping, looped directory detected
/usr/share/fonts/droid: skipping, looped directory detected
/usr/share/fonts/encodings: skipping, looped directory detected
/usr/share/fonts/gsfonts: skipping, looped directory detected
/usr/share/fonts/liberation: skipping, looped directory detected
/usr/share/fonts/misc: skipping, looped directory detected
/usr/share/fonts/noto: skipping, looped directory detected
/usr/share/fonts/noto-cjk: skipping, looped directory detected
/usr/share/fonts/encodings/large: skipping, looped directory detected
/var/cache/fontconfig: not cleaning unwritable cache directory
/home/aidanb/.cache/fontconfig: cleaning cache directory
/home/aidanb/.fontconfig: cleaning cache directory
fc-cache: succeeded

Here's my current version:

cat /etc/lsb-release
DISTRIB_ID="ManjaroLinux"
DISTRIB_RELEASE="24.1.2"
DISTRIB_CODENAME="Xahea"
DISTRIB_DESCRIPTION="Manjaro Linux"

Please help! Thank you.

I have built uboot and linux for qemu-x86_64 and I am booting u-boot.rom and then try to boot linux from there, but I think cpu resets when I execute zboot command and uboot starts again. Here is my command with which I start qemu: qemu-system-x86_64 -m 1024 -M pc -bios u-boot.rom -drive file=rootfs.ext2.img,format=raw,if=virtio -kernel bzImage -net nic,model=virtio -net user -serial mon:stdio I have created rootfs.ext2.img as mentioned in the following post create image with partition table in order for uboot to recognize the virtio device. The main problem is that when I try to boot linux the last message is "Loading bzImage at address 100000 (4820640 bytes)" and then uboot is started again. Here is the log starting from error, I did not put the uboot boot logs twice not to duplicate:

Load address: 0x1000000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=> ext2load virtio 0:1 0x1000000 /boot/bzImage
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
dev=virtio, devnr=0:1, path=/boot/bzImage, buffer=0000000001000000, size=49c6a0
Wrong FIT format: not a flattened device tree (err=-9)
- not remembering image
4834976 bytes read in 68 ms (67.8 MiB/s)
=> zboot 0x1000000
Valid Boot Flag
Setup Size = 0x00003800
Magic signature found
Using boot protocol version 2.0f
Linux kernel version 5.15.41 (mikhail@Prague) #1 SMP Wed Nov 6 10:12:54 CET 2024
Building boot_params at 0x00090000
Loading bzImage at address 100000 (4820640 bytes)

U-Boot SPL 2022.04 (Nov 05 2024 - 14:07:51 +0100)
notbr: returning err=-1
notbr: returning err=-1
notbr: returning err=-1
notbr: returning err=-1
notbr: returning err=-1
notbr: returning err=-1
Trying to boot from SPI
Jumping to 64-bit U-Boot: Note many features are missing
size=30, ptr=30, limit=1000: 1104e0
size=3c8, ptr=3f8, limit=1000: 110510
size=30, ptr=428, limit=1000: 1108d8
size=98, ptr=4c0, limit=1000: 110908
bind node chosen
Device 'chosen' has no compatible string
bind node aliases
Device 'aliases' has no compatible string
bind node memory
Device 'memory' has no compatible string
bind node serial
   - attempt to match compatible string 'ns16550'
   - found match at 'ns16550_serial': 'ns16550' matches 'ns16550'
size=30, ptr=4f0, limit=1000: 1109a0
size=98, ptr=588, limit=1000: 1109d0
size=28, ptr=5b0, limit=1000: 110a68
bind node keyboard
   - attempt to match compatible string 'intel,i8042-keyboard'
Skipping device pre-relocation
bind node reset
   - attempt to match compatible string 'x86,reset'
   - found match at 'x86_reset': 'x86,reset' matches 'x86,reset'
size=30, ptr=5e0, limit=1000: 110a90
size=98, ptr=678, limit=1000: 110ac0
size=8, ptr=680, limit=1000: 110b58
bind node rtc
   - attempt to match compatible string 'motorola,mc146818'
   - found match at 'motorola_mc146818': 'motorola,mc146818' matches 'motorola,mc146818'
size=30, ptr=6b0, limit=1000: 110b60
size=98, ptr=748, limit=1000: 110b90
bind node tsc-timer
   - attempt to match compatible string 'x86,tsc-timer'
   - found match at 'x86_tsc_timer': 'x86,tsc-timer' matches 'x86,tsc-timer'
size=30, ptr=778, limit=1000: 110c28
size=98, ptr=810, limit=1000: 110c58
bind node smbios
   - attempt to match compatible string 'u-boot,sysinfo-smbios'
Skipping device pre-relocation
bind node config
Device 'config' has no compatible string
bind node cpus
Device 'cpus' has no compatible string
bind node pci
   - attempt to match compatible string 'pci-x86'
   - found match at 'pci_x86': 'pci-x86' matches 'pci-x86'
size=30, ptr=840, limit=1000: 110cf0
size=98, ptr=8d8, limit=1000: 110d20
bind node pch@1,0
   - attempt to match compatible string 'intel,pch7'
   - found match at 'intel-pch7': 'intel,pch7' matches 'intel,pch7'
size=30, ptr=908, limit=1000: 110db8
size=98, ptr=9a0, limit=1000: 110de8
size=20, ptr=9c0, limit=1000: 110e80
bind node irq-router
   - attempt to match compatible string 'intel,irq-router'
No match for node 'irq-router'
bind node binman
Device 'binman' has no compatible string
size=8, ptr=9c8, limit=1000: 110ea0
size=20, ptr=9e8, limit=1000: 110ea8
size=18, ptr=a00, limit=1000: 110ec8


U-Boot 2022.04 (Nov 05 2024 - 14:07:51 +0100)

size=70, ptr=a70, limit=1000: 110ee0
size=1b8, ptr=c28, limit=1000: 110f50
notbr: returning err=-1
pre: returning err=-1
notbr: returning err=-1
pre: returning err=-1
pre: returning err=-1
pre: returning err=-1
size=30, ptr=c58, limit=1000: 111108
size=30, ptr=c88, limit=1000: 111138
size=98, ptr=d20, limit=1000: 111168
size=18, ptr=d38, limit=1000: 111200
bind node cpu@0
   - attempt to match compatible string 'cpu-qemu'
   - found match at 'cpu_qemu': 'cpu-qemu' matches 'cpu-qemu'
size=98, ptr=dd0, limit=1000: 111218
size=20, ptr=df0, limit=1000: 1112b0
CPU:   QEMU Virtual CPU version 2.5+
DRAM:  size=30, ptr=e20, limit=1000: 1112d0
size=8, ptr=e28, limit=1000: 111300
size=30, ptr=e58, limit=1000: 111308
1 GiB
bind node chosen
Device 'chosen' has no compatible string
bind node aliases
Device 'aliases' has no compatible string
bind node memory
Device 'memory' has no compatible string
bind node serial
   - attempt to match compatible string 'ns16550'
   - found match at 'ns16550_serial': 'ns16550' matches 'ns16550'
bind node keyboard
   - attempt to match compatible string 'intel,i8042-keyboard'
   - found match at 'i8042_kbd': 'intel,i8042-keyboard' matches 'intel,i8042-keyboard'
bind node reset
   - attempt to match compatible string 'x86,reset'
   - found match at 'x86_reset': 'x86,reset' matches 'x86,reset'
bind node rtc
   - attempt to match compatible string 'motorola,mc146818'
   - found match at 'motorola_mc146818': 'motorola,mc146818' matches 'motorola,mc146818'
bind node tsc-timer
   - attempt to match compatible string 'x86,tsc-timer'
   - found match at 'x86_tsc_timer': 'x86,tsc-timer' matches 'x86,tsc-timer'
bind node smbios
   - attempt to match compatible string 'u-boot,sysinfo-smbios'
   - found match at 'sysinfo_smbios': 'u-boot,sysinfo-smbios' matches 'u-boot,sysinfo-smbios'
bind node smbios
Device 'smbios' has no compatible string
bind node config
Device 'config' has no compatible string
bind node cpus
Device 'cpus' has no compatible string
bind node pci
   - attempt to match compatible string 'pci-x86'
   - found match at 'pci_x86': 'pci-x86' matches 'pci-x86'
bind node pch@1,0
   - attempt to match compatible string 'intel,pch7'
   - found match at 'intel-pch7': 'intel,pch7' matches 'intel,pch7'
bind node irq-router
   - attempt to match compatible string 'intel,irq-router'
No match for node 'irq-router'
bind node binman
Device 'binman' has no compatible string
binman: Selected image node 'rom'
Core:  10 devices, 10 uclasses, devicetree: separate
0
   - -1 'pci'
   - not found
vesa_video_bind: Frame buffer size fa0000
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
Loading Environment from nowhere... OK
0
   - 0 'vesa_video'
   - found
No x resolution: returning err=-6
returning err=-6
0
   - 0 'vesa_video'
   - found
Incorrect expansion ROM header signature 4daa
returning err=-22
Model: QEMU x86 (I440FX)
Net:   No ethernet found.
bind node cpu@0
   - attempt to match compatible string 'cpu-qemu'
   - found match at 'cpu_qemu': 'cpu-qemu' matches 'cpu-qemu'
smbios_version = 00000000000f00bf: '2022.04'
Hit any key to stop autoboot:  0 
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
scanning bus for devices...

Device 0: unknown device

Device 0: 1af4 VirtIO Block Device
            Type: Hard Disk
            Capacity: 61.0 MB = 0.0 GB (124928 x 512)
... is now current device
 
 
 
Scanning virtio 0:1...
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Scanning disk virtio-blk#1...
unhandled device class: virtio-pci.l#1 (virtio)
unhandled device class: pci (pci)
 
 
 
Found 2 disks
No EFI system partition
Initializing EFI driver framework
Adding EFI driver 'EFI block driver'
Incorrect expansion ROM header signature 4daa
returning err=-22
0
   - 0 'virtio-net#0'
   - found
0
   - 0 'virtio-net#0'
   - found
unhandled device class: virtio-pci.l#0 (virtio)
unhandled device class: pci (pci)
smbios_version = 000000003dcec03f: '2022.04'
BootOrder not defined
EFI boot manager: Cannot load any image
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Reset IDE: Bus 0: OK Bus 1: OK 
  Device 0: not available
  Device 1: not available
  Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
            Type: Removable CD ROM
            Capacity: not available
  Device 3: not available

Device 0: unknown device
starting USB...
No working controllers found
0
   - 0 'virtio-net#0'
   - found
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (2 ms)
Using virtio-net#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x7000000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (1 ms)
Using virtio-net#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x1000000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...

I've also gathered some information by adding **-d int,pcall,cpu,cpu_reset,guest_errors -D qemu.log** and there is a triple fault before cpu reset. The exception causing the triple fault:

check_exception old: 0xffffffff new 0xd
     1: v=0d e=0000 i=0 cpl=0 IP=0010:72b63af36fd82b54 pc=72b63af36fd82b54 SP=0018:000000000010e6b8 env->regs[R_EAX]=0000000000100000
RAX=0000000000100000 RBX=0000000000498ea0 RCX=0000000000000000 RDX=0000000000000000
RSI=000000000149c6a0 RDI=0000000000598ea0 RBP=0000000001000000 RSP=000000000010e6b8
R8 =0000000000000000 R9 =0000000000100000 R10=000000000010e46e R11=00000000000186a0
R12=0000000000000001 R13=000000000000020f R14=000000003eff6280 R15=0000000000003800
RIP=72b63af36fd82b54 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-]
SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0020 0000000000110118 00003fff 00809300 DPL=0 DS   [-WA]
GS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl
GDT=     00000000fffddc20 0000002f
IDT=     0000000000120000 000007ff
CR0=80000011 CR2=0000000000000000 CR3=0000000000080000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000000 CCD=0000000000000000 CCO=SUBQ
EFER=0000000000000500
check_exception old: 0xd new 0xd
     2: v=08 e=0000 i=0 cpl=0 IP=0010:72b63af36fd82b54 pc=72b63af36fd82b54 SP=0018:000000000010e6b8 env->regs[R_EAX]=0000000000100000
RAX=0000000000100000 RBX=0000000000498ea0 RCX=0000000000000000 RDX=0000000000000000
RSI=000000000149c6a0 RDI=0000000000598ea0 RBP=0000000001000000 RSP=000000000010e6b8
R8 =0000000000000000 R9 =0000000000100000 R10=000000000010e46e R11=00000000000186a0
R12=0000000000000001 R13=000000000000020f R14=000000003eff6280 R15=0000000000003800
RIP=72b63af36fd82b54 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-]
SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0020 0000000000110118 00003fff 00809300 DPL=0 DS   [-WA]
GS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl
GDT=     00000000fffddc20 0000002f
IDT=     0000000000120000 000007ff
CR0=80000011 CR2=0000000000000000 CR3=0000000000080000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000000 CCD=0000000000000000 CCO=SUBQ
EFER=0000000000000500
check_exception old: 0x8 new 0xb

If a CPU exception in kernel, such as bad memory access or invalid opcode, happens in the context of servicing a user process (like syscall or page-in), or in a kthread process, then, until panic_on_oops was set, useful information will be dumped and the task will just die. No panic. Sometimes the system remains absolutely usable. Enough for the user to attempt syncing their disks, gracefully terminating programs, and in other ways preparing for the emergency restart. But unfortunately, if the exception happens in atomic context (like interrupt or softirq), the action taken is **always Kernel Panic** (with description "Fatal exception in interrupt") — regardless of any settings or build-time configurations. It is sad. Why it's not possible to simulate a return from interrupt, and keep the system running in hope that some parts will still function? Thanks. I know that I can put an infinite mdelay() in the code path of "exception in interrupt" instead of panic(), to just stall the local CPU instead. But usually not much things can be done after that happens... Even if there are hundred CPUs in machine, they all soon lock up. So not very useful.

My machine's architecture is x86_64 and I've cross-compiled arm64 assembly (from [here](https://peterdn.com/post/2020/08/22/hello-world-in-arm64-assembly/)) into an executable. However the binary is still runnable on my machine... how? Here are the outputs to the following commands:

$ uname -r 
6.2.12-100.fc36.x86_64

$ file hello
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped

$ ./hello
Hello, ARM64

$ qemu-aarch64-static hello
Hello, ARM64

$ qemu-x86_64-static hello
qemu-x86_64-static: hello: Invalid ELF image for this architecture

$ readelf -a hello 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x4000b0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          264 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         2
  Size of section headers:           64 (bytes)
  Number of section headers:         4
  Section header string table index: 3

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         00000000004000b0  000000b0
       0000000000000030  0000000000000000  AX       0     0     8
  [ 2] .data             PROGBITS         00000000004100e0  000000e0
       000000000000000d  0000000000000000  WA       0     0     1
  [ 3] .shstrtab         STRTAB           0000000000000000  000000ed
       0000000000000017  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x00000000000000e0 0x00000000000000e0  R E    0x10000
  LOAD           0x00000000000000e0 0x00000000004100e0 0x00000000004100e0
                 0x000000000000000d 0x000000000000000d  RW     0x10000

 Section to Segment mapping:
  Segment Sections...
   00     .text 
   01     .data 

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type AArch64 is not currently supported.

No version information found in this file.

When trying to use screenshare with audio on vesktop, I got an error from the app that read "your c++ library is too old to run venmic", which prompted me to try and update it. I followed the steps: sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt-get update sudo apt-get install --only-upgrade libstdc++6 **I also updated my gcc through the software manager right after**. The packages that were removed from these commands were: intel-media-va-driver:i386 libgl1:i386 libgl1-mesa-dri:i386 libglx-mesa0:i386 libglx0:i386 libicu70:i386 libigdgmm12:i386 libllvm15:i386 libnvidia-fbc1-535:i386 libstdc++6:i386 libva-glx2:i386 libxml2:i386 mesa-va-drivers:i386 mesa-vulkan-drivers:i386 steam:i386 steam-libs-i386:i386 va-driver-all:i386 I didn't think much of it since it was getting replaced by other libraries, sadly I don't remember which ones, though I didn't notice the "nvidia-firmware" or "steam-devices" packages. I also thought that it would be simple to undo this procedure afterwards so I kept it going. Vesktop was working afterwards but some other apps were not, so I then tried undoing it by reinstalling all the removed apps, assuming it would remove the libstdc++6 and replace it with a different one. Here's what happened: sudo apt install intel-media-va-driver:i386 libgl1:i386 libgl1-mesa-dri:i386 libglx-mesa0:i386 libglx0:i386 libicu70:i386 libigdgmm12:i386 libllvm15:i386 libnvidia-fbc1-535:i386 libstdc++6:i386 libva-glx2:i386 libxml2:i386 mesa-va-drivers:i386 mesa-vulkan-drivers:i386 steam:i386 steam-libs-i386:i386 va-driver-all:i386 Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: intel-media-va-driver:i386 : Depends: libstdc++6:i386 (>= 11) but it is not going to be installed libgl1-mesa-dri:i386 : Depends: libstdc++6:i386 (>= 11) but it is not going to be installed Recommends: libgl1-amber-dri:i386 but it is not installable libicu70:i386 : Depends: libstdc++6:i386 (>= 5.2) but it is not going to be installed libigdgmm12:i386 : Depends: libstdc++6:i386 (>= 4.1.1) but it is not going to be installed libllvm15:i386 : Depends: libstdc++6:i386 (>= 12) but it is not going to be installed E: Unable to correct problems, you have held broken packages. libglx-mesa0:i386: command not found libnvidia-fbc1-535:i386: command not found mesa-va-drivers:i386: command not found steam-libs-i386:i386: command not found I tried removing the libstdc++6 package to see if it would be replaced by something else and I got this: sudo apt-get remove libstdc++6 Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: apt : Depends: libapt-pkg6.0 (>= 2.4.12) but it is not going to be installed Depends: libstdc++6 (>= 11) but it is not going to be installed mintsources : Depends: python3-apt but it is not going to be installed Depends: python3-gi but it is not going to be installed Depends: python3-gi-cairo but it is not going to be installed Depends: python3-pycurl but it is not going to be installed Depends: python3-requests but it is not going to be installed Depends: mint-common (>= 2) but it is not going to be installed Depends: gir1.2-gdkpixbuf-2.0 but it is not going to be installed Depends: gir1.2-gtk-3.0 but it is not going to be installed Depends: gir1.2-vte-2.91 but it is not going to be installed Depends: gir1.2-xapp-1.0 but it is not going to be installed Depends: lsb-release but it is not going to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. I tried installing libstdc++6:i386 and this happened: sudo apt install libstdc++6:i386 Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: apt : Depends: libapt-pkg6.0 (>= 2.4.12) but it is not going to be installed Depends: libstdc++6 (>= 11) but it is not installable mintsources : Depends: python3-apt but it is not going to be installed Depends: python3-gi but it is not going to be installed Depends: python3-gi-cairo but it is not going to be installed Depends: python3-pycurl but it is not going to be installed Depends: python3-requests but it is not going to be installed Depends: mint-common (>= 2) but it is not going to be installed Depends: gir1.2-gdkpixbuf-2.0 but it is not going to be installed Depends: gir1.2-gtk-3.0 but it is not going to be installed Depends: gir1.2-vte-2.91 but it is not going to be installed Depends: gir1.2-xapp-1.0 but it is not going to be installed Depends: lsb-release but it is not going to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. I tried fixing the broken packages and got this: sudo apt --fix-broken install Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: i965-va-driver:i386 libatomic1:i386 libbrotli1:i386 libdrm-amdgpu1:i386 libdrm-intel1:i386 libdrm-nouveau2:i386 libdrm-radeon1:i386 libedit2:i386 libelf1:i386 libfontconfig1:i386 libfreetype6:i386 libglib2.0-0:i386 libgnutls30:i386 libhogweed6:i386 libnettle8:i386 libnm0:i386 libp11-kit0:i386 libpciaccess0:i386 libpng16-16:i386 libsensors5:i386 libtasn1-6:i386 libva-drm2:i386 libva-x11-2:i386 libva2:i386 libvulkan1:i386 libxcb-glx0:i386 libxcb-shm0:i386 libxfixes3:i386 libxi6:i386 libxinerama1:i386 libxss1:i386 libxxf86vm1:i386 nvidia-firmware-535-535.171.04 steam-devices Use 'sudo apt autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded. I then noticed that Steam was gone from my apps, and when trying to install it again, I ran into an error as well: The following packages have unmet dependencies: apt: Depends: libapt-pkg6.0 (>= 2.4.12) but it is not going to be installed Depends: libstdc++6 (>= 11) but it is not installable mintsources: Depends: python3-apt but it is not going to be installed Depends: python3-gi but it is not going to be installed Depends: python3-gi-cairo but it is not going to be installed Depends: python3-pycurl but it is not going to be installed Depends: python3-requests but it is not going to be installed Depends: mint-common (>= 2) but it is not going to be installed Depends: gir1.2-gdkpixbuf-2.0 but it is not going to be installed Depends: gir1.2-gtk-3.0 but it is not going to be installed Depends: gir1.2-vte-2.91 but it is not going to be installed Depends: gir1.2-xapp-1.0 but it is not going to be installed Depends: lsb-release but it is not going to be installed So what happened and what do I do? I've never had this problem before, and I've used outside repos before. I haven't run the autoremove command out of fear of breaking things further, but it seems like those packages are the ones causing problems. I'm running Linux Mint 21.1 and I'm not sure which c++ library is the proper one for this system, I'd just like to get things back to how they were. **The apt policy command for libstdc++6 and libstdc++6:i386**: apt policy libstdc++6 libstdc++6:i386 libstdc++6: Installed: 13.1.0-8ubuntu1~22.04 Candidate: 13.1.0-8ubuntu1~22.04 Version table: *** 13.1.0-8ubuntu1~22.04 100 100 /var/lib/dpkg/status 12.3.0-1ubuntu1~22.04 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 12-20220319-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages libstdc++6:i386: Installed: (none) Candidate: 12.3.0-1ubuntu1~22.04 Version table: 12.3.0-1ubuntu1~22.04 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main i386 Packages 12-20220319-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

I recently built a workstation and am running into issues getting Linux to boot. After a lot of trial and error (because mostly the behavior I see is indefinite hangs) I think I've narrowed the issue down to the USB enumeration. If I am able to boot to Linux, is there a way to discern which USB hubs are internal (to the South Bridge) and which are external on the motherboard? I am trying to determine if (1) what my options are for fixing the issue and (2) if I should either consider RMAing my SoC (AMD 5975WX) or my motherboard (Asus WRX80E-SAGE SE WIFI II). Surely there is some characteristic of PCIe hierarchy that makes the distinction clear? What I am able to see from the Linux early boot is

xhci_hcd 0000:23:00.0: init 0000:23:00.0 fail, -16
xhci_hcd 0000:2a:00.1: init 0000:2a:00.1 fail, -16
xhci_hcd 0000:2a:00.3: init 0000:2a:00.3 fail, -16

16 is EBUSY, which sounds like an interesting failure mode. Using this PCI bus enumeration can the origin of the failure be known?

For no reason, I've tried to read /dev/mem on a Linux x86_64 laptop using

cat /dev/mem > /dev/null

Under the root user, and my kernel was built without any restrictions on /dev/mem. I knew that /dev/mem's driver provides access to physical memory. And physical memory addresses can be mapped to different hardware and peripherals, so it may be unsafe to write to them. But I thought that read is fine.
But something went wrong, I saw few traces dumped to TTY (VT's), and the last line was saying note: cat[THE_PID] exited with irqs disabled.
After one or two seconds, it rebooted automatically, I don't know why (there was likely no kernel panic, and anyway I had kernel.panic=0 in sysctl, so it shouldn't have rebooted by itself).
I firstly ofc thought it was absolutely fine (just a crash, as always after "experiments"). **But then it turned out that a permanent issue was introduced by these actions**.
On the next boot, after loading of i915 driver for the iGPU, screen brightness automatically went to zero. I had to manually increase /sys/class/backlight/intel_backlight/brightness in the sysctl, for the brightness to be restored. Now, **on every boot, when the iGPU driver gets loaded, brightness goes zero, requiring an intervention**.
I have tried:
- Resetting EFI/BIOS - Deleting all efivars and booting the firmware cleanly - Zeroing out /dev/nvram and booting the firmware cleanly - Booting from a different disk (where there was a different Linux installation, different kernel version). None of these helped. Everything else works, but the brightness issue remains. I have to blindly set the brightness every boot, or using a script to run on boot, after modprobe i915 takes place. It's fine then, but I really want to know why that happened. Not exactly to fix it, but just because I'm really curious about how such thing could happen.
As I suppose, there was some physical address in /dev/mem which was mapped to the iGPU's non-volatile memory with some brightness preferences? But I have only done a read, not write.
Unfortunately I don't have the traces and regs which were dumped to TTY when cat died (because the machine rebooted nearly immediately, nothing was saved anywhere).
Thanks for any insights!

I'm trying to install Navicat which is an x86-64 binary onto my aarch64 machine, which results in "cannot execute binary file: Exec format error" Here's the result of running

on the executable:

-sqlserver-en.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped

And here is my

-a

:

penguin 4.19.98-08076-g24ab33fb8e14 #1 SMP PREEMPT Wed Apr 1 17:17:36 PDT 2020 aarch64 GNU/Linux

Is there any way to run this executable on my machine? (Idk if this makes any difference but I'm running Linux on my Samsung Chromebook Plus w/ an OP1 processor)

How can I tell whether my processor has a particular feature? (64-bit instruction set, hardware-assisted virtualization, cryptographic accelerators, etc.) I know that the file /proc/cpuinfo contains this information, in the flags line, but what do all these cryptic abbreviations mean? For example, given the following extract from /proc/cpuinfo, do I have a 64-bit CPU? Do I have hardware virtualization? model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz … flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority

On x86-64 Linux, there are two options for running 32-bit applications: one can be built into the kernel itself via the option CONFIG_IA32_EMULATION (normally on for most kernels), and the other is qemu-i386. What are the differences? Can qemu-i386 run near native performance – it is more like native, or is it more like a JIT recompiler?

I just created a simple .deb package (using this tutorial ). This is my control file:

Package: bla
Version: 1.0
Architecture: x86_64
Maintainer: bla
Description: bla

The Architecture I got from uname -m: x86_64, however, dpkg-deb broke due to _ being an invalid char, so I changed to - which worked but broke on the installation phase:

dpkg: error processing archive bla_x86_64.deb (--install):
 package architecture (x86-64) does not match system (amd64)

So I turned to use amd64 as my architecture, and voila! Now I just don't understand this mismatch in architectures between uname -m and dpkg...

I want to read the Intel iTCO watchdog registers on my Intel Lynx Point system. I found the watchdog here: [ 5598.341020] iTCO_wdt iTCO_wdt.1.auto: Found a Lynx Point TCO device (Version=2, TCOBASE=0x1860) It is connected to the ISA bridge LPC controller: 00:1f.0 ISA bridge: Intel Corporation H87 Express LPC Controller (rev 05) Subsystem: ASUSTeK Computer Inc. H87 Express LPC Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: lpc_ich Kernel modules: lpc_ich I found the ioports: cat /proc/ioports | grep -i tco 1830-1833 : iTCO_wdt.1.auto 1830-1833 : iTCO_wdt 1860-187f : iTCO_wdt.1.auto 1860-187f : iTCO_wdt And I found the iomem: cat /proc/iomem | grep -i wdt fed1f410-fed1f414 : iTCO_wdt.0.auto I tried to dump the memory via: memtool md 0xfed1f410 Then I set the timeout to a different value and compare the registers again: wdctl -s 10 memtool md 0xfed1f410 Nothing changes, why is that? What is wrong with my approach?