Category: Computer bits

Computer stuff

Posted on

452: Out of range pointer error

For the last couple weeks, my computer has been up and down, spitting out an error when booting up:

452: out of range pointer: 0x100010
Backgrace (.text 0xa058 .data 0x15a6c):
Aborted. Press any key to exit.

It started happening after rebooting following an update. Internet searches I did brought up some older forum posts that pointed to grub being the cause. Since it had been several Fedora versions (before Fedora 30 I think) since I last reinstalled and the system was feeling a bit crusty, I figured I’d just start fresh with a new install.

Wrestled with getting a Fedora 37 live image to boot off, did a reinstall and updates, rebooted, and ended up with the same message. Did this a couple times and started investigating the hardware.

Several iterations of testing the DDR3 memory modules and pulling out hard drives, I managed to get my computer back up and running with 8GB less memory, two 500 GB drives and a 250 GB SSD (the original boot drive) removed. All of the memory tested fine individually but with all of them installed, memtest consistently gave errors when performing one test the 21-22 GB range. Not sure if something’s happened to one of the memory slots, but the system stayed pretty stable for a few days.

Then, after reinstalling some software, running some updates, and rebooting, the error came back.

Ugh.

At this point, rather than reinstall again, I tried reinstalling the bootloader and rebuilt the grub config file. Rebooted and the system came back up without any issues.

Still don’t know what caused the breakage, but it’s been pretty stable so far the past few days. Let’s hope it stays that way. It’s running a bit slower because now I’m back to booting off a regular hard drive (1 TB) rather than an SSD. At some point I might try to put the other 8 GB back in to see how stable the system stays. I’d been having some problems with the computer intermittently freezing up at random points, so I’ll just leave it like this for a while. The 500 GB drives will go into a couple other systems that I inherited a while back. I think one of them will be put to work in the garage, probably on the CNC mill. The other one might end up being used with the radio in the shack.

I tried to reinstall Fedora on the 250 GB SSD drive, but the install would always freeze in the middle of doing something. Even though the drive’s SMART status shows it’s fine, I suspect it has started to develop some issues somewhere.

Posted on

Fedora KDE, Plasma Wayland, and Emacs

My previous attempts at using Fedora KDE with Wayland were pretty miserable, and KDE was pretty much unusable under Wayland with the nVidia drivers. Never tried it with the nouveau drivers at the time, but after dumping the nVidia drivers a while back, I thought I’d give KDE Plasma Wayland another shot.

I don’t know if Wayland support under KDE got better or if it’s because I’m not using the nVidia drivers anymore (probably both), but I’m finding Plasma is pretty snappy under Wayland.

I normally have emacs started as a systemd service (systemd --user start emacs) which runs emacs in daemon mode. Then I can just run emacsclient and have it connect to the already running emacs. One big issue I came across was not being able to run emacsclient and getting an *ERROR*: Display :0 can't be opened when I ran emacsclient -c from the command line.

The general consensus I found after searching the web for a while seemed to be that with systemd, the emacs daemon was starting before the graphical environment (Plasma), so display related environment variables weren’t available to emacs. Why this only happened with Plasma Wayland and not with Plasma X11, I don’t know.

When the emacs systemd service is enabled (systemd --user enable emacs), /usr/lib/systemd/user/emacs.service is symlinked into ~/.config/systemd/user/default.target.wants. My first attempt to fix the issue was to move emacs.service to graphical-session.target.wants, but that didn’t help.

Thinking about the apparent root cause of the issue, I found a Unix StackExchange post about how to have systemd services start in a particular order. I copied /usr/lib/systemd/user/emacs.service to ~/.config/systemd/user and linked it into graphical-session.target.wants. Then I added two lines to the [Unit] section:

Requires=plasma-kwin_wayland.service
After=plasma-kwin_wayland.service

This makes emacs.service a dependency of plasma-kwin_wayland.service and delays starting until after plasma-kwin_wayland.service has finished starting.

After rebooting and logging back in, I verified that the emacs daemon was still starting up (systemd --user status emacs) and was able to get emacsclient -c to bring up the emacs window. Everything was back to working the way I expected.

Posted on

Xorg and a Barco monitor

I’ve added a nice big Barco MDCC-6230 6 megapixel monitor to my work computer. The monitor comes from a radiology diagnostic workstation that was being taken out of commission, so I managed to get the monitor and an nVidia Quadro P1000 video card to drive it.

Out of the box, I had a hard time getting Fedora to use the resolutions the monitor was capable of and it would only run the Barco monitor at 1024×768.

Thanks to the collective knowledge of the Internet, I figured out how to use xrandr to get the video card to drive the monitor at its full resolution (3280×2048) and arrange the displays the way I wanted them.

# Create a new display mode.  Modeline info came from the Xorg log file.
# (II) NOUVEAU(0): Modeline "1640x2048"x49.9  188.50  1640 1688 1720 1800  2048 2051 2061 2097 +hsync -vsync (104.7 kHz UP)
xrandr --newmode "1640x2048" 188.50  1640 1688 1720 1800  2048 2051 2061 2097 +hsync -vsync

# Add the new modes to the video card outputs connected to the Barco
xrandr --addmode DP-1 1640x2048
xrandr --addmode DP-2 1640x2048

# Configure the video card outputs
xrandr --output DP-2 --mode 1640x2048 --pos 0x0 --primary
xrandr --output DP-1 --mode 1640x2048 --right-of DP-2
xrandr --output DP-3 --mode 1600x1200 --pos 3280x848

Unfortunately, whenever I logged out or rebooted, the computer reverted to the original 1024×768 configuration. Getting the display configuration to persist across logins and reboots meant getting X Windows configured properly. It took a while, but I figured out a working set of xorg.conf configuration directives that worked (placed in /etc/X11/xorg.conf.d/10-monitor.conf).

Section "Device"
    Identifier     "Device0"
    Driver         "nouveau"
    VendorName     "NVIDIA Corporation"
    BoardName      "Quadro P1000"
    Screen         0
    Option         "Monitor-DP-1" "Monitor0"
    Option         "Monitor-DP-2" "Monitor1"
    Option         "Monitor-DP-3" "Monitor2"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    Option         "Monitor-DP-1" "Monitor0"
    VendorName     "Barco"
    ModelName      "BDS MDCC-6230"
    ModeLine       "1640x2048"  188.50  1640 1688 1720 1800  2048 2051 2061 2097 +hsync -vsync
    Option         "PreferredMode" "1640x2048"
    Option         "DPMS"
    Option         "Position" "1640 0"
    Option         "DisplaySize" "327 409"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    Option         "Monitor-DP-2" "Monitor1"
    VendorName     "Barco"
    ModelName      "BDS MDCC-6230"
    ModeLine       "1640x2048"  188.50  1640 1688 1720 1800  2048 2051 2061 2097 +hsync -vsync
    Option         "PreferredMode" "1640x2048"
    Option         "DPMS"
    Option         "Primary"
    Option         "Position" "0 0"
    Option         "DisplaySize" "327 409"
EndSection

Section "Monitor"
    Identifier     "Monitor2"
    Option         "Monitor-DP-3" "Monitor2"
    VendorName     "Planar Systems"
    ModelName      "PX212M"
    ModeLine       "1600x1200"  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync
    Option         "PreferredMode" "1600x1200"
    Option         "DPMS"
    Option         "Position" "3280 848"
    Option         "DisplaySize" "432 324"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    Monitor        "Monitor1"
    Monitor        "Monitor2"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    EndSubSection
    Option         "metamodes" "DP-2: 1640x2048 +0+0, DP-1: 1640x2048 +1640+0, DP-3: 1600x1200 +3280+848"
EndSection

The Xorg log tells me some of the configuration directives aren’t used, but everything works so I’ll leave it alone for now.

Now my work computer desktop has a total of 3280×2048 + 1600×1200 pixels (across two monitors) of workspace for me to do stuff in. I wonder if I can get Xorg set up so that the Barco gets used as a single monitor instead of two virtual monitors.

Posted on

Building an emacs config

I have a long history of dabbling with emacs, having discovered it during my latter undergrad years (the emacs 18 era). I’d pick it up for a while, and then go back to whatever editor I happened to be using at the time. I liked emacs, but using it wasn’t anything that ever really stuck with me. Part of the reason was that I didn’t really have a solid use case for something like emacs. Emacs also has a not-so insignificant learning curve and getting into it can be pretty overwhelming and intimidating.

When I started on the PhD, I made a concerted effort to make emacs one of my primary tools, having learned about things like org-mode and distributions like spacemacs and doom-emacs from other people.

Org-mode makes setting up something like a research notebook pretty easy, and getting started is pretty simple. The basics are pretty easy to learn and when you want to do something more advanced, the documentation is very good.

Now, after spending the past couple of years of using emacs routinely, I’ve decided it’s time to learn more and start crafting my own emacs configuration. I’ll get to learn a little more elisp and dive into some of the packages I’ve become used to using. Might be something I keep and continue to evolve, or I might go back to spacemacs. Maybe I’ll try something else later.

It feels kind of like when a Jedi reaches the point in their training when they make their own light saber.

Posted on

Peeking inside the Altair 680

Let’s have a look inside the Altair 680 that I acquired at the hamfest a couple years ago.

Undoing four screws at the back of the unit releases the back (surprise!) and top cover to reveal the inside.

Inside the Altair 680 showing the power supply at the bottom, and circuit boards
Inside the Altair 680

The back plate has the power supply consisting of two chunky transformers, a fan, and DB25 connector. There’s also an empty spot for another DB25 connector. Thanks to the two transformers, the rear panel is fairly hefty. The DB25 connector looks like it only has 4 wires. Not sure what would be connected to it, but probably something serial terminal related. There’s not a lot of clearance between the transformers and the SRAM chips on the main board when the rear panel is in place.

Altair 680 rear panel with two transformers, DB25 connector and cooling fan
Altair 680 rear panel with two transformers, DB25 connector and cooling fan
Altair 680 rear panel. Not a whole lot of clearance between the transformers on the rear panel and the main board.
Altair 680 rear panel. Not a whole lot of clearance between the transformers on the rear panel and the main board.

Removing the expansion board (I’ll get to that in a bit) reveals the main board.

Altair 680 main board
Altair 680 main board
Motorola MC6800 CPU in the Altair 680
Motorola MC6800
EPROM chip in the Altair 680. Appears to be room for 3 more EPROMs.
EPROM and some SRAM chips
Motorola MC6850 asynchronous communications interface adapter
Motorla MC6850

The Motorola MC6800 CPU that powers the 680 is up toward the expansion board connector. Toward the bottom rear of the main board are 8 1kbit Intel P2102 SRAM chips that provides the 680 with 1 kB of RAM. Above the RAM is an EPROM (looks like an AM 1702A EPROM). The empty sockets seem like they would provide space for 3 more EPROMs. The other notable chip on the main board is the MC6850 asynchronous communications interface adapter.

Over in the front corner of the board by the big 3.3 mF filtering capacitor, the silk screen says this 680 main board is Rev 1-6.

680 Main board Rev 1-6
680 Main board Rev 1-6

The only expansion board in this 680 appears to be a RAM expansion board. The riser card has room for 3 slots, but the two other spots are unpopulated.

Altair 680 expansion board with one connector and two unpopulated connector spaces.
Altair 680 expansion board connector

The RAM board contains an 8×4 bank of Semi 4200UCP chips. A Google search didn’t yield a whole lot of information about them, but they appear to be 4kbit SRAM chips, so this board provides the Altair with a whopping 16 kB of additional memory to play with.

Photo of the Altair 680 memory board. A 8x4 bank of 4 kbit static RAM chips provides 64k of RAM.
RAM board

When I plugged it in and turned it on, the fan spun up and some lights came on!

Altair 680 front panel showing some data LEDs turned on.
Altair 680 front panel showing some data LEDs turned on.

No smoke released, but the data lights turning on even though most of the switches were in the down position indicates something’s not quite right. Changing the switch positions didn’t affect anything either. The Run light on even though the switch is in the HLT position also suggests something isn’t quite right. Toggling the HLT/RUN switch made the HLT LED blink on once. Toggling the RESET switch didn’t seem to affect anything. The address line switches all seem to work, but LEDs started blinking when A13 was switched on.

Altair 680 front panel with the first 8 address line switches turned on
Altair 680 front panel with the first 8 address line switches turned on
Altair 680 front panel with the all 16 address line switches turned on
Altair 680 front panel with the all 16 address line switches turned on

Looks like this unit might need some work to restore it to a functioning state. I’ll also need to do some more research to learn about how the 680 works.

Back into the closet it goes for now.