Sig-I/O (Posts about linux)

Debian on a Thinkpad T14 AMD Gen5

Mark Janssen — Sun, 21 Jul 2024 14:48:22 GMT

Intro

Since my previous workhorse laptop was showing it's age, I had been looking for a replacement for a while. After much deliberation, I got the choice down to 2 options; The Frame.Work 13 with AMD Ryzen and 2.8K display (which is still in pre-order phase), and the Thinkpad T14 AMD Gen5 which can also be had with a 2.8K OLED display.

I've always been a Thinkpad user (at least for the last 20 years), and I've tried out the Frame.Work when some friends had one around, but I keep preferring the Lenovo keyboards and trackpad with buttons (for the trackpoint). The Lenovo also had the advantage of coming with more ports, as it has 2x USB-C, 2x USB-A and seperate UTP, HDMI and Minijack, where the Frame.Work only has the 4 USB-C ports with optional modules for other ports. The Thinkpad was also available directly (built-to-order, but with a 1 week lead-time) and seems to be as repairable as the Frame.Work, and comes with 3-year warranty and on-site service. So the Thinkpad was my choice again this time.

Specs

Thinkpad T14 AMD Gen 5
2.8K Matte OLED
AMD Ryzen 7 Pro 8840U
8GB Ram, but have upgraded this after-market to 64GB DDR5-5600
256GB WD-Black SSD, replaced with a 2TB model after-market (m2.2280)
No OS, which gets you a $60 discount at Lenovo
Fingerprint reader, Smartcard reader, both seem to 'work'

Installation

Installation of debian 12 went reletively smooth, though I did run into some issues downloading the kernel-package from the updates repository, which seems to have gotten corrupted. This was fixed by doing the installation from a German mirror first, and changing back to deb.debian.org later. For better support I've also enabled the bookworm-backports repository and installed the latest bpo kernel (6.9.7+bpo-amd64) at this time.

Secure-boot and UEFI didn't give me any issues and running with Luks+LVM+XFS also went smooth.

The only hardware related issue I've run into at this time, is the occasional amdgpu crashes (hopefully fixed now) and a hang when connecting to my thunderbolt-dock with attached HDMI monitor. In this case the AMDGPU driver tries to (and fails/hangs) read the EDID information for the HDMI monitor, and this pauses/hangs the entire system unill either the dock or the monitor is disconnected. Sometimes the monitor will be recognised as a 640x480 screen, and the system will continue, but this is quite useless.

For now I've disconnected the 2nd monitor from the dock, and it's connected directly to the HDMI port on the laptop, and there it works fine in 4k 60Hz mode (which is all this Acer KG281K can do).

Software setup

After 20+ years of using Gnome (and mostly Mate/Gnome-Classic the last few years), I've switched over to KDE on this laptop. So far I quite like it, but I've had to make some small tweaks here and there to get it working how I'm used to.

I quite like the KDE-Connect android app, which lets me control the laptop from the phone, This will be nice to use for presentations.

AMD GPU

The amdgpu driver and firmware that came with debian 12 has been giving me some issues, with random crashes of the GPU and wayland drivers, but after a lot off fiddling, it seems to be stable now with the following combination of changes from debian 12 default:

Install latest backport kernel
Manually install latest amdgpu firmware from kernel.org mirror
Add the 'amdgpu.gpu_recovery=1 rtc_cmos.use_acpi_alarm=1' options to the kernel commandline

Weirdness

The specsheet/ordersheet from Lenovo claims the display is 60Hz, but KDE's display properties will let me choose 120Hz on the internal display.
Even in idle (with just some browsers running) the fans seem to be running at a quite audible level around 3000rpm, causing a constant wind-noise. For the time being i've propped up the laptop on a stand, which seems to keep it a bit cooler than just standing flat on my desk the entire day.

Linux Leap-Second problem

Mark Janssen — Tue, 03 Jul 2012 21:03:16 GMT

So, this weekend was quite an interesting one, as on July 1st 02:00 local time (00:00 UTC) a leap-second was added via NTP. This caused serious problems for all my Java Virtual Machines and mysql databases.

If your system has printed the following line (in dmesg), a leap-second has been added recently:

Clock: inserting leap second 23:59:60 UTC

On most of my systems, the JVM’s would spike to 100% cpu load over all cores, mysql seems to also do this.

The work-around/fix at this time is to run:

date date +"%m%d%H%M%C%y.%S"

Hopefully this will be fixed in the kernel before the next leap-second is added. Which could be as soon as 2013/01/01, though probably later.

Update 2018:

It was indeed fixed before the next leap-second, which occurred somewhere not too long after. I haven't encountered this problem since.

Resetting failed drive in linux mdadm raid array

Mark Janssen — Thu, 12 Apr 2012 21:05:19 GMT

Today I was greeted with a failed drive in a mdadm raid array. The drive had some transient errors and was kicked out of the array, but testing showed that the drive still seemed to work just fine.

Image by Martin Abegglen (https://www.flickr.com/photos/twicepix/3333710952)

The following procedure will remove the drive from the array, remove it from the system, re-probe for disks, and then re-add the drive back into the array(s).

Remove the failed drive from the array, in this case, it was /dev/sdb:
- mdadm --manage --set-faulty /dev/md0 /dev/sdb1
Make sure nothing on this disk is being used (mounts, other arrays, etc)
Reseat the drive from the system, either physically, or using the following commands:
- echo 1 > /sys/block/sdb/device/delete
- echo "- - -" > /sys/class/scsi_host/host1/scan
Check if the drive is found again, and check if it works correctly
- check dmesg output, or look at /proc/partitions
- try running: ‘pv < /dev/sdb of=/dev/zero‘
Re-add the drive to the array(s)
- mdadm /dev/md0 -a /dev/sdb1
- cat /proc/mdstat

That should do the trick…

Run-time editing of limits in Linux

Mark Janssen — Tue, 14 Feb 2012 21:24:21 GMT

On CentOS and RHEL Linux (with kernels >= 2.6.32) you can modify resource-limits (ulimit) run-time. This can be done using the /proc/<pid>/limits functionality. On older kernels this file is read-only and can be used to inspect the limits that are in effect on the process. On newer systems you can modify the limits with echo:

cat /proc/pid/limits echo -n "Max open files=soft:hard" > /proc/pid/limits cat /proc/pid/limits

On older systems you will have to modify limits before starting a process.

(See also the post on serverfault)

If you are not running CentOS/RHEL, you can use the ‘prlimit’ command, which does the same thing, but doesn’t rely on a patch that’s no longer present in current kernels.

Online resizing of multipath devices in Linux dm-multipath

Mark Janssen — Thu, 07 Apr 2011 21:26:24 GMT

Linux doesn’t automatically re-size multipath devices, so this procedure must be used to have online re-sizing of multipath. (Offline re-size is automatic, just remove the mapping and reload)

this example will use multipath device /dev/mpath/testdisk, with scsi disks /dev/sdx and /dev/sdy
Resize the lun on the underlying storage layer (iscsi / san)
Check which sd? devices are relevant, and re-scan these:
- multipath -ll testdisk
- blockdev –rereadpt /dev/sdx
- blockdev –rereadpt /dev/sdy
- blockdev –getsz /dev/sdx
- blockdev –getsz /dev/sdy
Take note of the new size returned by getsz.
Dump the dmsetup table to a file (and a backup)
- dmsetup table testdisk | tee mapping.bak mapping.cur
Edit the table stored in ‘mapping.cur’
- vi mapping.cur, replace field 2 (size) with the new size from getsz
Suspend I/O, reread the table, and resume I/O
- dmsetup suspend testdisk; dmsetup reload testdisk mapping.cur; dmsetup resume testdisk
The multipath device should now be resized:
multipath -ll

You can now resize the filesystem on the multipath device, or the LVM-PV if you use LVM on the LUN.